EP1929796A2 - Systeme et procede de communication de lecteur a lecteur rfid - Google Patents

Systeme et procede de communication de lecteur a lecteur rfid

Info

Publication number
EP1929796A2
EP1929796A2 EP06751150A EP06751150A EP1929796A2 EP 1929796 A2 EP1929796 A2 EP 1929796A2 EP 06751150 A EP06751150 A EP 06751150A EP 06751150 A EP06751150 A EP 06751150A EP 1929796 A2 EP1929796 A2 EP 1929796A2
Authority
EP
European Patent Office
Prior art keywords
reader
readers
tags
network
rfid
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP06751150A
Other languages
German (de)
English (en)
Inventor
Sayan Chakraborty
Brain Mckinney
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
SkyeTek Inc
Original Assignee
SkyeTek Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US11/323,214 external-priority patent/US7570164B2/en
Priority claimed from US11/328,209 external-priority patent/US20060253415A1/en
Priority claimed from US11/387,422 external-priority patent/US20070046431A1/en
Application filed by SkyeTek Inc filed Critical SkyeTek Inc
Publication of EP1929796A2 publication Critical patent/EP1929796A2/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
    • G06K7/00—Methods or arrangements for sensing record carriers, e.g. for reading patterns
    • G06K7/0008—General problems related to the reading of electronic memory record carriers, independent of its reading method, e.g. power transfer
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
    • G06K7/00—Methods or arrangements for sensing record carriers, e.g. for reading patterns
    • G06K7/10—Methods or arrangements for sensing record carriers, e.g. for reading patterns by electromagnetic radiation, e.g. optical sensing; by corpuscular radiation
    • G06K7/10009—Methods or arrangements for sensing record carriers, e.g. for reading patterns by electromagnetic radiation, e.g. optical sensing; by corpuscular radiation sensing by radiation using wavelengths larger than 0.1 mm, e.g. radio-waves or microwaves
    • G06K7/10316—Methods or arrangements for sensing record carriers, e.g. for reading patterns by electromagnetic radiation, e.g. optical sensing; by corpuscular radiation sensing by radiation using wavelengths larger than 0.1 mm, e.g. radio-waves or microwaves using at least one antenna particularly designed for interrogating the wireless record carriers
    • G06K7/10356—Methods or arrangements for sensing record carriers, e.g. for reading patterns by electromagnetic radiation, e.g. optical sensing; by corpuscular radiation sensing by radiation using wavelengths larger than 0.1 mm, e.g. radio-waves or microwaves using at least one antenna particularly designed for interrogating the wireless record carriers using a plurality of antennas, e.g. configurations including means to resolve interference between the plurality of antennas

Definitions

  • RFID Radio-frequency Identification
  • RFID readers RFID tag readers
  • RFID tags 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.
  • 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.
  • the RFED 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.
  • FIG. 1 shows a prior art system 8 that reads data from RFED tags.
  • System 8 has two RFED readers 10(1) and 10(2) and a server 22.
  • Server 22 includes two reader interfaces 24(1), 24(2), RFED middleware 26 with RFIDStack 28, and two applications 30(1), 30(2).
  • Each RFED reader 10 includes a controller 12, an RFED radio circuit 14 and a host interface 16.
  • Each RFED radio circuit 14 connects to an antenna 18 used to communicate with one or more RFED tags 20.
  • RFED middleware 26 communicates with each application 30 and each RFED reader 10; for example, RFED middleware 26 utilizes reader interface 24(1) to communicate with RFED reader 10(1) and utilizes reader interface 24(2) to communicate with RFED reader 10(2).
  • Each RFED 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.
  • 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.
  • 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.
  • RFID radio frequency identification
  • 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.
  • RFID radio frequency identification
  • 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.
  • RFID radio frequency identification
  • a method determines a scope of operation of one or more radio frequency identification (RFDD) readers within an RFID reader network.
  • 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.
  • RFDD radio frequency identification
  • a method coordinates a plurality of radio frequency identification (RFBD) 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.
  • 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.
  • RFID radio frequency identification
  • 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.
  • a method creates a network of radio frequency identification (RFDD) readers.
  • a first RFDD reader is initially included in the network and additional RFDD 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.
  • RFDD radio frequency identification
  • 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.
  • RFID radio frequency identification
  • 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.
  • 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 RFDD reader directly coupled to the server and operating as a proxy server.
  • the readers are couple to create an RFDD reader network such that the proxy server exchanges information between the server and the at least one reader not directly connected to the server.
  • a system interacts with one or more radio frequency identification (RFDD) tags and includes a first set of one or more RFDD 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 RFDD reader network such that the proxy server exchanges information between the server and the at least one reader not directly connected to the server.
  • FIG. 1 shows a prior art system for reading data from RFDD tags.
  • FIG. 2 shows one exemplary system for RFDD reader to reader communication, in accord with an embodiment.
  • FIG. 3 shows exemplary system architecture utilized within each RFDD 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 RFDD 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 RFK) readers within an RFlD 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.
  • RFID radio frequency identification
  • a radio frequency identification (RFID) reader is used to identify RFlD 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.
  • UID unique identification number
  • tags may be addressed using their UIDs.
  • 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.
  • additional commands e.g., write block, read block, lock block, etc
  • the reader may read data from one or more memory blocks of the selected tag using a read block command.
  • the reader may write data to one or more memory blocks of the selected tag using a write command.
  • the reader may prevent further changes to one or more memory blocks of the selected tag using a lock command.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 number: / , 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 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.
  • 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.
  • MAC message authentication code
  • 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.
  • application software interface 212 may provide many functions associated with reading RFlD tags.
  • 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.
  • 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 FO 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 RFDD 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.
  • API 334 is portable and platform independent whereas driver functions within hardware abstraction layer 318 may be dependent upon platform 302.
  • 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.
  • a host e.g., server 106, FIG. 2
  • stream 320 may include drivers for TTL, I 2 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 FO 324 includes drivers that provide hardware interface handling for communication with sensors and other VO devices that connect to hardware of platform 302.
  • sensor and J/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.
  • 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.).
  • 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.
  • 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).
  • RFID radio 332 drivers may enable data-defined aspects of operation at the physical layer to be effectuated.
  • 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.
  • 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.
  • CRC cyclical redundancy code
  • parity calculation library forward error correction algorithms
  • message data parsers ASCII to hexadecimal encoders and decoders
  • host-protocol command interpreters host-protocol command executors
  • host-protocol error handlers host-protocol error handlers.
  • 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.
  • 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.
  • 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.).
  • 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 RFED 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.
  • 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.
  • 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
  • manufacturer functions which enable applications to access manufacturer-specific features of a standards- based tag and utilize independent tag manufacturers proprietary tag protocols.
  • tag protocol 348 may support a variety of protocols including ISO15693- 2, ISO18000, ISO14443-2 Type A, ISO14443-2 Type B, Phillips ICode SLl, Texas Instruments Tag-it HF and TagSys C210, C220 and future protocols.
  • 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 RFED 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.
  • 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.
  • 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.
  • 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.).
  • 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).
  • 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:
  • 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
  • UDDI Universal Description, Discovery and Integration
  • LDAP Lightweight Directory Access Protocol
  • a 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.
  • 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:
  • 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).
  • a known 'key' e.g. an X.509 certificate
  • 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.
  • SAML Security Assertion Markup Language
  • a reader network e.g., reader network 105
  • 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).
  • a mutually agreed upon authentication source e.g. a LDAP server, ideally the same central authoritative source used for discovery.
  • AuthenticationMethod "urn: oasis :names : tc :SAML: 1.0 : am:password”
  • Authenticationlnstant 2006-03-16T17 : 05 : 17.706Z”> ⁇ sa ⁇ nl : Subjects
  • 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 NotOnOr After). Thus readers may be required to re- authenticate after expiration of their SAML assertions.
  • a token e.g. a password
  • a central authentication source e.g., a central authoritative source 107 within server 106
  • 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.
  • SSL Secure Sockets Layer
  • TLS Transport Layer Security
  • 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).
  • 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.
  • a reader may send a capability message to a second reader, as shown below:
  • This capability message may be extended by adding information about specific functions/items supported by the reader. For example:
  • 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).
  • 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.
  • 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' .
  • a central authoritative source may be utilized to store the location/address of each reader within a directory.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the reader should not connect as an active routing 'node' within the network, but simply connect as a leaf node.
  • 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).
  • 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.
  • time service 502 may utilize network manager 360, FIG. 4, to effect communication with other networked readers 102.
  • readers 102 that have overlapping operational fields can coordinate read and write operations as described below.
  • each reader queries a Network Time Protocol (NTP) server, thereby obtaining an accurate time.
  • NTP Network Time Protocol
  • an NTP server is not available (or is not accessible by all readers)
  • readers join the reader network they are synchronized with the reader network time.
  • a first reader 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.
  • 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.
  • 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.
  • Ih step 532 groups of readers where reader to reader transmission interference occurs within readers of the group are determined.
  • 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.
  • 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.
  • step 534 a first set consisting of one reader from each group determined in step 532 is selected.
  • reader 102(2) is selected for the first set.
  • step 536 a second set including remaining readers of each group not in the first set is selected " .
  • readers 102(1) and 102(3) are selected for the second set.
  • step 538 the first set of readers is coordinated to operate in transmit only mode.
  • reader 102(2) is coordinated to operate in transmit only mode.
  • step 540 the second set of readers is coordinated to operate in a receive only mode.
  • readers 102(1) and 102(3) are coordinated to operate in the receive only mode.
  • 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.
  • the read period of readers 102(1) and 102(3) is synchronized with the transmit period of reader 102(2).
  • coordination of the readers to operate in a synchronized manner may eliminate cross reader interference.
  • each reader may select a different frequency slot for operation thereby also eliminating cross reader interference.
  • 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;
  • 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.
  • 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.
  • 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.
  • 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.
  • a plurality of readers may be used to determine (e.g., by triangulation) the location of one or more tags.
  • 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).
  • reader 102(1) interacts with reader 102(2) and host version and capability structure 414 of each reader is exchanged.
  • 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).
  • the updated software is transferred within the CDATA section of a XML message.
  • the updated software is transferred as a FTP-like binary transfer.
  • 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.
  • a predetermined "quiet" time e.g., after business hours
  • 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.
  • 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.
  • 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.
  • 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.
  • tag information received by reader 102(2) first passes to reader 102(3) and then to server 106.
  • reader manager 356 utilizes functionality of proxy server 606 within reader 102(3) to relay information between reader 102(2) and server 106.
  • 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 IP address and/or the order in which it joined the network).
  • the protocol e.g. a hash of the reader name and its IP address and/or the order in which it joined the network.
  • Server 106 detects available readers by issuing a management message:
  • 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.
  • FIG. 9 shows data manager 358 of FIG. 4 and illustrates functionality of tag data 702 and search and locate 704.
  • data manager 358 utilizes functionality of tag data 702 to share tag cache entries with one or more other networked readers.
  • 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.
  • tag cache operation may be found in US Patent Application Number: _/__, titled “System and Method for Implementing Virtual RFID Tags".
  • 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;
  • a reader 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.
  • tags enter and exit the reader's operational field rapidly e.g., they are located upon a fast moving conveyer
  • an upstream source e.g., a server
  • the tag cache allows the reader to queue operations for later consumption by the server.
  • 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).
  • server 106 issues a message, indicating that it requires information relating to a specific tag ID, to a reader network.
  • 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.
  • 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.
  • the following message may represent an exemplary search return:
  • each targeted reader may return results for the search.
  • an upstream entity e.g. a user or a server
  • decides which result is more relevant e.g., based upon 'lastSeen' or 'reader' or some other metric).
  • a user may also issue search requests, using a server, for 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:
  • UID unique identifier
  • FIG. 10 is a block diagram illustrating one exemplary 'swarm' 800 of three readers, 802, 804 and 806 within a reader network 822.
  • 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.
  • location A may represent an entrance to a warehouse
  • location B may represent at a start of a conveyor belt 811 within the warehouse
  • 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.
  • 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., UBDs 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.
  • readers 804 and 806 have identification information of tags 812, 814, 816, 818 and 820 before palette 810 arrives in locations B and C.
  • 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.
  • 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.
  • 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.
  • reader 802 updates readers 804 and 806 with data 828 (i.e., UE)s 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.
  • 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.
  • Other protocols and communication medium may be used without departing from the scope hereof.
  • 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 OxOf) and other tag attributes (e.g. tag types such as ISO15693).
  • meta data e.g. time, reader location
  • tags whose values have changed within a defined period of time e.g. 'Hello World' at OxOf
  • data stored within tags e.g. 'Hello World' at OxOf
  • 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.
  • a first set of one or more of the plurality of readers is coordinated to operate in a transmit only mode.
  • reader 102(2), FIG. 2 is coordinated to operate in a transmit only more.
  • a second set of one or more of the plurality of readers is coordinated to operate in receive only mode.
  • readers 102(1) and 102(3) are 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 of readers coincides with a transmit period of the first set of readers.
  • 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.
  • a first set of one or more reader at a first location is configured to identify a plurality of tags to determine identification information.
  • reader 802, FIG. 10, at location A identifies tags 812, 814, 816, 818 and 820.
  • 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.
  • reader 804 interacts with tag 812.
  • 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.
  • 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.
  • the plurality of readers is communicatively coupled to create a reader network wherein not all of the readers are directly connected to the server.
  • 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.
  • 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.
  • reader 102(3) connects to serve 106 and forms a proxy server for exchanging information between server 106 and reader 102(2).

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Toxicology (AREA)
  • Health & Medical Sciences (AREA)
  • Artificial Intelligence (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Theoretical Computer Science (AREA)
  • Electromagnetism (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Near-Field Transmission Systems (AREA)

Abstract

L'invention concerne un système et un procédé permettant de coordonner plusieurs lecteurs d'identification par radiofréquence (RFID) de façon à minimiser le bruit du lecteur et accroître sa sensibilité. Un premier ensemble d'un ou de plusieurs des lecteurs est coordonné de façon à fonctionner en mode émission uniquement. Un second ensemble d'un ou de plusieurs des lecteurs est coordonné de façon à fonctionner en mode réception uniquement. Le premier et le second ensembles sont synchronisés de façon qu'une période de réception coïncide avec une période d'émission du premier ensemble.
EP06751150A 2005-08-31 2006-04-21 Systeme et procede de communication de lecteur a lecteur rfid Withdrawn EP1929796A2 (fr)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US71295705P 2005-08-31 2005-08-31
US11/323,214 US7570164B2 (en) 2005-12-30 2005-12-30 System and method for implementing virtual RFID tags
US11/328,209 US20060253415A1 (en) 2005-04-21 2006-01-09 Data-defined communication device
US11/387,422 US20070046431A1 (en) 2005-08-31 2006-03-23 System and method for combining RFID tag memory
PCT/US2006/015346 WO2007027220A2 (fr) 2005-08-31 2006-04-21 Systeme et procede de communication de lecteur a lecteur rfid

Publications (1)

Publication Number Publication Date
EP1929796A2 true EP1929796A2 (fr) 2008-06-11

Family

ID=37809317

Family Applications (1)

Application Number Title Priority Date Filing Date
EP06751150A Withdrawn EP1929796A2 (fr) 2005-08-31 2006-04-21 Systeme et procede de communication de lecteur a lecteur rfid

Country Status (2)

Country Link
EP (1) EP1929796A2 (fr)
WO (1) WO2007027220A2 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012176113A1 (fr) 2011-06-22 2012-12-27 Koninklijke Philips Electronics N.V. Dispositif d'affichage autostéréoscopique doté d'une fonction d'agrandissement optique

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103995361B (zh) * 2014-06-17 2017-01-11 上海新视觉立体显示科技有限公司 裸眼3d显示像素单元及多视图裸眼3d图像显示设备
DE112018000705T5 (de) 2017-03-06 2019-11-14 Cummins Filtration Ip, Inc. Erkennung von echten filtern mit einem filterüberwachungssystem
CN111050875B (zh) 2017-08-30 2022-07-05 康明斯滤清系统知识产权公司 用于正品过滤器识别的联锁装置

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0730458A (ja) * 1992-11-06 1995-01-31 Texas Instr Deutschland Gmbh 多重呼掛部、データ通信およびトランスポンダ装置
US5649295A (en) * 1995-06-19 1997-07-15 Lucent Technologies Inc. Dual mode modulated backscatter system
US5777561A (en) * 1996-09-30 1998-07-07 International Business Machines Corporation Method of grouping RF transponders
US5952922A (en) * 1996-12-31 1999-09-14 Lucent Technologies Inc. In-building modulated backscatter system
US7411921B2 (en) * 1999-10-21 2008-08-12 Rf Technologies, Inc. Method and apparatus for integrating wireless communication and asset location

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2007027220A3 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012176113A1 (fr) 2011-06-22 2012-12-27 Koninklijke Philips Electronics N.V. Dispositif d'affichage autostéréoscopique doté d'une fonction d'agrandissement optique

Also Published As

Publication number Publication date
WO2007027220A3 (fr) 2009-04-23
WO2007027220A2 (fr) 2007-03-08

Similar Documents

Publication Publication Date Title
US20070046467A1 (en) System and method for RFID reader to reader communication
EP3639536B1 (fr) Nom et enregistrement de la blockchain pour l'internet des objets
EP3304431B1 (fr) Registre ouvert pour l'identité d'objets
US20190141504A1 (en) Cloud and smartphone communication system and method
US8565680B2 (en) Method and apparatus for provisioning a device
KR101183334B1 (ko) 장치 서비스 공급자 인터페이스
CN1667645B (zh) 与识别标签通信的方法和系统
CN102111192B (zh) 一种蓝牙连接方法及系统
CN101149782B (zh) 用于协调应用的信息处理装置和方法
US8275858B2 (en) Method for updating firmware of radio frequency identification reader through network system
EP2235914B1 (fr) Procédé et système de gestion d'un réseau d'entités distribuées
WO2003012720A1 (fr) Procede et systeme de gestion de reseaux d'approvisionnement
ZA200506980B (en) Device service provider interface
Carbunar et al. Efficient tag detection in RFID systems
WO2007027220A2 (fr) Systeme et procede de communication de lecteur a lecteur rfid
US9565513B1 (en) Systems and methods for providing long-range network services to short-range wireless devices
Qiao et al. RFID as an Infrastructure
US20050156022A1 (en) Systems and methods for establishing communication between an identification tag reader and a computing device
CN113170376B (zh) 用于装置集群管理的系统和方法
Floerkemeier et al. RFID applications: interfacing with readers
KR101227154B1 (ko) 무선 주파수 식별 태그용 리더장치 및 그의 통신방법
WO2023212698A1 (fr) Systèmes, dispositifs et procédés de démarrage sécurisé de capteurs rfid
KR20060070289A (ko) Ｒｆｉｄ와 웹서비스를 이용하여 장치정보를 등록하고제공하는 시스템 및 그 방법

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20080328

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL BA HR MK YU

R17D Deferred search report published (corrected)

Effective date: 20090423

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20091031