EP1872598A2 - Systeme de fonctionnement d'un lecteur rfid et structure associee - Google Patents

Systeme de fonctionnement d'un lecteur rfid et structure associee

Info

Publication number
EP1872598A2
EP1872598A2 EP06750968A EP06750968A EP1872598A2 EP 1872598 A2 EP1872598 A2 EP 1872598A2 EP 06750968 A EP06750968 A EP 06750968A EP 06750968 A EP06750968 A EP 06750968A EP 1872598 A2 EP1872598 A2 EP 1872598A2
Authority
EP
European Patent Office
Prior art keywords
layer
application
api
driver
framework
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
EP06750968A
Other languages
German (de)
English (en)
Other versions
EP1872598A4 (fr
Inventor
Sean T. Loving
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/301,587 external-priority patent/US20060238304A1/en
Priority claimed from US11/301,396 external-priority patent/US20060238302A1/en
Priority claimed from US11/301,770 external-priority patent/US20060238305A1/en
Priority claimed from US11/301,423 external-priority patent/US20060238303A1/en
Priority claimed from US11/328,209 external-priority patent/US20060253415A1/en
Priority claimed from US11/387,422 external-priority patent/US20070046431A1/en
Priority claimed from US11/387,421 external-priority patent/US7659819B2/en
Application filed by SkyeTek Inc filed Critical SkyeTek Inc
Publication of EP1872598A2 publication Critical patent/EP1872598A2/fr
Publication of EP1872598A4 publication Critical patent/EP1872598A4/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

Definitions

  • RFID stands for Radio-Frequency IDentification.
  • An RFID transponder or 'tag', serves a similar purpose as a bar code or a magnetic strip on the back of a credit card; it provides an identifier for a particular object, although, unlike a barcode or magnetic strip, some tags support being written to.
  • An RFID system carries data in these tags, and retrieves data from the tags wirelessly. Data within a tag may provide identification for an item in manufacture, goods in transit, a location, the identity of a vehicle, an animal, or an individual. By including additional data, the ability is provided for supporting applications through item-specific information or instructions available on reading the tag.
  • a basic RFID system includes a reader or 'interrogator 1 and a transponder (RF tag) electronically programmed with unique identifying information. Both the transceiver and transponder have antennas, which respectively emit and receive radio signals to activate the tag, read data from the tag, and write data to it.
  • An antenna is a feature that is present in both readers and tags, and is essential for the communication between the two.
  • An RFID system requires, in addition to tags, a mechanism for reading or interrogating the tags and usually requires some means of communicating RFID data to a host device, e.g., a computer or information management system.
  • the antenna is packaged with the transceiver and decoder to become a reader (an 'interrogator 1 ), which can be configured either as a handheld or a fixed-mount device.
  • the reader emits radio waves in ranges of anywhere from one inch to 100 feet or more, depending upon its power output and the radio frequency used.
  • an RFID tag passes through the electromagnetic zone (its 'field') created by the reader, it detects the reader's activation signal.
  • the reader decodes the data encoded in the tag's integrated circuit and the data is often passed to a device (e.g., a computer) for processing.
  • Two methods distinguish and categorize RFID systems, one based upon close proximity electromagnetic or inductive coupling, and one based upon propagating electromagnetic waves. Coupling is via 'antenna' structures forming an integral feature in both tags and readers. While the term 'antenna' is generally considered more appropriate for propagating systems it is also loosely applied to inductive systems.
  • the word transponder derived from TRANSmitter/resPONDER, reveals the function of a tag.
  • a tag responds to a transmitted or communicated request for the data it carries, the communication between the reader and the tag being wireless across the space between the two.
  • the essential components that form an RFID system are one or more tags and a reader or interrogator.
  • the basic components of a transponder are, generally speaking, fabricated as low power integrated circuit suitable for interfacing to an external coil, or utilizing 'coil-on-chip' technology, for data transfer and power generation, where the coil acts as an antenna matched to the frequency supported.
  • Reader/interrogators can differ quite considerably in complexity, depending upon the type of tags being supported and the functions to be fulfilled. However, their overall function is to provide a mechanism for communicating with the tags, providing power to passive tags, and facilitating data transfer. Functions performed by the reader may include signal conditioning, parity error checking and correction. Once the signal from a transponder has been correctly received and decoded, algorithms may be applied to decide whether the signal is a repeat transmission, and may then instruct the transponder to cease transmitting. This is known as a 'Command Response Protocol' and is used to circumvent the problem of reading multiple tags in a short space of time. Using interrogators in this way is sometimes referred to as 'Hands Down Polling'.
  • 'Hands Up Polling' An alternative, more secure, but slower tag polling technique is called 'Hands Up Polling', which involves the interrogator looking for tags with specific identities, and interrogating them in turn.
  • This technique requires contention management, and a variety of techniques have been developed to improve the process of batch reading, including anti-collision techniques.
  • the entire reader firmware module must typically be re-programmed (e.g., 're-flashed', in the typical case where the reader employs flash memory), or, in the case of multiple-processor readers, a relatively large part of the existing reader firmware must still be extensively re-programmed.
  • preexisting RFID readers allow modularity or granularity with respect to the security level of specific modules (drivers / applications, etc.), so that, for example, the code in pre-selected proprietary modules may be kept secure (i.e., remain undecipherable to an unauthorized user/programmer), while the code in other specific modules may be readily re-programmed.
  • RFID reader requirements vary widely from stationary label printers to handheld devices and from forklifts to dock doors. Indeed there remains a problem in the industry that no standard technology can support the spectrum of reader requirements - from power and frequency control, to host interfaces, to tag protocols and standards, as well as the wide variety of price/performance tradeoffs related to read range and rate, physical size, power consumption and cost.
  • a framework structure for controlling an RFID device including a platform comprising an RFID radio.
  • the structure comprises a layered framework including a first layer, with at least one functional module comprising a device driver, communicatively coupled with the platform; and a second layer, with at least one functional module comprising an API, communicatively coupled with the first layer and with an application for controlling the RFID device.
  • the framework structure includes a firmware stratum comprising a tiered plurality of the functional modules, with the stratum being integrated with the layered framework such that each tier of the stratum is layered to functionally correspond to one of the layers in the framework.
  • Figure 1 A is a diagram showing a prior art monolithic RFID reader connected to a host computer
  • Figure 1 B is a diagram showing a prior art monolithic RFID reader including an embedded processor
  • Figure 2 is a diagram of an exemplary embodiment of the present operating system framework for an RFID Reader, showing high-level architecture of the system
  • Figure 3A is a diagram of one embodiment of the present operating system for an RFID Reader showing, more specifically, the layered structure of the system architecture;
  • Figure 3B and Figure 3C are diagrams of one embodiment of the present operating system for an RFID Reader showing system architecture including the orthogonal relationship between the horizontally layered 'firmware stratum' and the vertically layered abstraction structure of the system architecture;
  • Figure 4A is a diagram showing exemplary hardware components which may be included in layer 209 of the present system.
  • Figure 4B is a diagram showing exemplary drivers which • may be included in layer 305 of the present system;
  • Figure 4C is a diagram showing exemplary library functions which may be included in layer 207 of the present system;
  • Figure 4D is a diagram showing exemplary library APIs which may be included in layer 207 of the present system;
  • FIG. 5 is a diagram of an exemplary embodiment of the present operating system for an RFID Reader including an application processor, a signal processor, and a discrete radio device;
  • FIG. 6 is a diagram of an exemplary embodiment of the present operating system for an RFID Reader including an integrated application / signal processor and transceiver;
  • Figure 7 is a diagram of an exemplary embodiment of the present operating system showing modularity and selectively of security with respect to the firmware components of the system;
  • Figure 8 is a flowchart showing an exemplary set of steps performed in initial setup of one embodiment of the present system.
  • Figure 9 is a flowchart showing an exemplary set of steps performed in operation of one embodiment of the present system.
  • the present RFID operating system ('RFID OS') comprises an open-architecture software architecture for RFID readers.
  • the system provides interoperability between generic RFID readers, system services, and applications.
  • the present architecture allows RFID reader functionality to be independent of RFID reader hardware architecture.
  • RFID services are layered on top of the RFID OS.
  • a service handler may facilitate a contactless payment transaction by invoking a particular application functionality via a tag protocol API (application programming interface), which in turn, calls one or more APIs to perform RF communication with RFID tags.
  • tag protocol API application programming interface
  • the present RFID operating system framework includes a layered architecture that can be used with a multiplicity of different RFID reader platforms.
  • the RFID OS framework interfaces with peripheral hardware, and may perform a number of different application functions such as task scheduling, protocol handling, and storage allocation.
  • the framework provides a default software interface between a host processor and an RFID reader when no application program is running on a particular reader.
  • FIG. 1 A is a diagram showing a prior art monolithic RFID reader 101 connected to a host computer
  • Figure 1B is a diagram showing a prior art monolithic RFID reader 102 including an embedded processor.
  • the RFID reader technology consists of monolithic hardwired devices with RFID reader control software/firmware.
  • the term "firmware” is defined as "software that is embedded in a hardware device", and, as used herein, the term implies only the 'software' code in a particular piece of hardware, irrespective of the particular hardware device containing the code.
  • Reader 101 is connected to an external host computer 100, and reader 102 has an embedded processor 105 which functions as a dedicated, fixed-capability host.
  • a host-specific API 103 is typically integral to the readers, and the reader functionality is pre- established and not modifiable by a user, since the functionality is 'buried' inside user-inaccessible firmware in a 'black box' 104.
  • the reader control features and functionality are set at compile time, thus making the readers 101/102 application-specific. Value- added software & middleware cannot be integrated into these existing readers by a typical user, thereby limiting the readers' performance.
  • FIG. 2 is a diagram of an exemplary embodiment 200 of the present operating system environment for an RFID reader, showing high- level aspects of the architecture of the system.
  • the present operating system architecture includes a 'vertical' framework 201 coupled between a host computer 220 (via a communications link 212) and an RFID reader platform 210.
  • platform 210 may be considered as a basic RFID reader / interrogator, minimally including hardware 209 and an RFID 'radio' 214, which may comprise a receiver or a transceiver, depending upon the particular application and type of RFID tag 230 for which the platform 210 is intended.
  • Radio 214 which includes an antenna (not shown), functions to exchange data with RFID tag 230 via RF link 202.
  • Reader platform 210 comprises on-board control software for an RFID reader that can be customized and built upon by third-party developers. This platform enables OEMs to easily RFID-enable new or existing devices.
  • Reader platform 210 may also include an embedded operating system 208, such as Linux or Windows CE. Platform 210 may be coupled to framework 201 via an operating system 208 running on the platform (through interface 204), or via RF communication with RFID radio 214, using an RF link 206. In the latter instance, the platform typically does not include operating system 208.
  • an operating system 208 such as Linux or Windows CE.
  • Platform 210 may be coupled to framework 201 via an operating system 208 running on the platform (through interface 204), or via RF communication with RFID radio 214, using an RF link 206. In the latter instance, the platform typically does not include operating system 208.
  • the present RFID OS vertical framework 201 is integrated with a horizontal firmware stratum (shown in Figures 3B-3C) to support a range of options for use with an RFID reader platform 210.
  • firmware components that can be used independently or in combination, a set of API extensions to embedded operating systems, and a stand-alone operating system for dedicated RFID reader architectures.
  • the vertical framework 201 for the present system comprises three layers, which are effectively situated 'on top of platform 210:
  • a hardware abstraction layer 203 including RFID reader hardware drivers and associated APIs
  • an RFID reader application software interface layer 205 including RFID reader software Libraries and associated APIs
  • an application layer 207 including application software for controlling reader platform 210.
  • FIG. 3A is a diagram of one embodiment of the present operating system for an RFID Reader showing, more specifically, the vertically layered structure of the system architecture.
  • the layered architecture of the present system allows applications and services to access a set of multiple library and driver APIs.
  • driver refers to (a) a program that controls a device, where a 'device' may be considered to be any type of hardware device, or circuit, or (b) another program that performs a function using a predefined protocol or set of instructions.
  • a driver acts like a translator between the device and programs that use the device.
  • framework 201 vertically tiered with respect to RFID reader application software interface layer 205 and hardware abstraction layer 203, both of which are also tiered or layered in a 'vertical' direction between reader platform 210 and application layer 207.
  • the application software interface layer 205 is tiered or divided into two functional sub-layers, a layer 305 including library functions (or modules), and a layer 306 including APIs for interfacing between the library functions and the application layer 207, as indicated by arrow 315 in Figure 3A.
  • library function refers to any software or firmware program code, which, although typically stored with other functions in a 'library', may exist in a context (or layer, in the present system) wherein no library is extant.
  • library function and “library module” are intended to refer to the same type of entity, as a result of the modular nature of the present system architecture.
  • the hardware abstraction layer 203 is also tiered or divided into two functional sub-layers, a layer 303 including hardware and communication device drivers (modules), and a layer 304 including driver APIs for interfacing between the drivers and corresponding library functions in API library function layer 305, as indicated by arrow 313.
  • the RFID OS vertical framework 201 includes an operating system kernel 301 which is always present, and various system programs 325 which use facilities provided by the kernel to perform higher-level 'housekeeping' tasks. Each of the vertical layers in the present system is described in greater detail immediately below.
  • the RFID operating system vertical framework 201 may be viewed as resting on top of the reader platform layer 210.
  • platform 210 includes hardware, plus an optional operating system 208 and developer tools 215.
  • a simple platform 210 might use 8-bit microcontroller hardware with no operating system; in this case, modules in RFID OS framework 201 serve as the device operating system.
  • the present system integrates with both the target operating system 208 and the platform hardware 209; in this case, portable RFID OS framework components reside in the different processors, logic blocks and ASICs that comprise a particular platform 210.
  • the open software architecture of the RFID OS framework 201 together with the horizontal layering of the firmware stratum (described below) facilitates integration of RFID radio hardware with most types of processors and OS platforms.
  • FIG. 4A is a diagram showing exemplary hardware components which may be included in platform hardware 209 of the present system. As shown in Figure 4A, these hardware components may include, for example, processor 402, processor main memory 404, cache memory 406, user interface 408, sensors and associated I/O devices 410, and RFID radio 214. Hardware Abstraction Layer / Drivers
  • driver APIs in sub-layer 304 of hardware abstraction layer 203 function as the software interface for the low- level software drivers that directly control reader hardware 209.
  • the driver APIs in sub-layer 304 of layer 203) are platform-independent.
  • the code that implements each driver is, however, platform-specific. Typically, only a small amount of code in each low-level driver requires modification when porting to a new platform.
  • the hardware abstraction layer 203 in RFID OS framework 201 provides portability for On- reader' applications, and platform-independence across RFID-enabled devices.
  • FIG 4B is a diagram showing exemplary drivers which may be included in layer 303 of the present system.
  • drivers include RFID radio control functions, peripheral hardware control functions and host interface hardware control functions. More specifically, as shown in Figure 4B, these drivers may include, for example, a user interface driver 414, and communications drivers such as those shown in blocks 416-424.
  • sub-layer 305 of application software interface layer 205 includes a library of functions or modules
  • sub-layer 306 includes one or more libraries of APIs defining the software interface used by an application to access internal RFID reader functionality, via the functions in sub-layer 305.
  • the library APIs 306 are platform-independent, as are the code implementations of the library functions in sub-layer 305.
  • code is used herein to refer to Object code', which is code produced by a compiler from 'source code', usually in the form of machine language that a computer (e.g., a microprocessor) can execute directly.
  • the present system allows the use of multiple APIs for On-device' applications to control device hardware and low-level functionality in a standard manner, regardless of the device- embedded computing platform 210.
  • Such platforms 210 range from DSP architectures to microprocessor cores with an operating system to microcontroller-based devices, sensors and objects, with or without an operating system.
  • Application Layer [0050] Applications in application layer 207, as well as in host 100 /
  • the RFID reader hardware and platform 210 may indirectly access any of the lower layers (205, 203, 210) in the system architecture via a set of APIs 304/306.
  • a set of APIs 304/306 By accessing the RFID reader hardware and platform 210 via the abstraction layers provided by the libraries and drivers, 'on-reader' applications become portable across devices employing the present architecture.
  • This abstraction layering makes third- party-generated RFID reader software and tag protocol libraries independent of the underlying hardware, thus facilitating the integration of embedded computing intelligence into sensors, devices and ordinary objects.
  • hardware abstraction layer 203 may include one or more drivers and no API(s).
  • application software interface layer 205 may include only (one or more) APIs and no library functional modules.
  • an API in layer 305 / 205 directly calls a corresponding driver in layer 303 / 203 to control reader hardware 209.
  • Figure 4C is a diagram showing exemplary library functions which may be included in sub-layer 305 of the present system. Examples of library functions include tag functions, security functions and reader configuration functions, such as those shown in blocks 426-436 of Figure 4C.
  • Figure 4D is a diagram showing exemplary library APIs 438- 448, which may be included in sub-layer 306 of layer 205 of the present system. As shown in Figure 4D, these library APIs generally correspond to counterpart library functions in sub-layer 305.
  • on-reader applications make function calls to library functions, which, in turn, call driver functions which control the reader hardware.
  • application layer 207 of the present system includes one or more of these applications.
  • Figure 3B and Figure 3C are diagrams of one embodiment of the present RFID reader operating system architecture showing exemplary tiers or levels of functionality provided by 'horizontal' firmware layering in a 'firmware stratum' 350.
  • the architecture of the present system is best understood by viewing Figures 3B and 3C in conjunction with one another, wherein the orthogonal relationship between the horizontally layered firmware stratum 350 and the vertically layered abstraction structure 201 (*) [where the asterisk indicates one of a plurality of similar items] of the system architecture is shown.
  • Firmware stratum 350 is a collection of modules, which, when considered as being 'stacked' along a horizontal plane, is positioned orthogonally relative to the vertical layering of framework 201.
  • Each of the layers (tiers) in the firmware stratum is hereinafter termed a "level" 33X (e.g., 331-338) thereof, and each of the levels of the firmware stratum is layered in accordance with the three-tiered scheme 201 shown in Figure 2 and Figure 3A.
  • firmware stratum levels 331- 338 in Figure 3B correspond to levels 201 (1) - 201 (N) in Figure 3C.
  • firmware stratum 350 The orthogonal relationship between firmware stratum 350 and the layering of composite structure 201 (*) is indicated in Figure 3B by the relationship between arrow 350, which shows the 'horizontal' layering of the firmware stratum, and arrow 355, which shows the 'vertical' layering of each of the components or 'levels' of the firmware stratum.
  • Each level 33X of firmware stratum 350 includes one, two, or three modules, the aggregate of which may include an API, a library function (or other functional component), and a driver. Thus, each stratum level 33X is itself layered in the three-tiered scheme of framework structure 201.
  • Table 1 lists specific modules or other functional components that may be included in the firmware stratum 350 in an exemplary embodiment of the present system.
  • each level 33X may be further subdivided into sub-levels, each of which is designated in the Table as being a member of a respective higher level, as indicated in Figures 3B and 3C.
  • FIG. 3 SUB-
  • FIG. 5 is a diagram of an exemplary embodiment of the present operating system architecture 500 for an RFID reader including an application processor 506, a signal processor 504, and a discrete radio device 502.
  • RFID radio software 514 resides in a signal processor (e.g., block 504), digital state machine or both, and application software 518 and radio-specific software 516 reside in a main application processor 506.
  • Software/firmware modules 516 / 518 in application processor 506 communicate with radio software 514 and digital hardware 512 in signal processor 504 via APIs, libraries, and drivers 305/306 and 303/304, as described above with respect to the embodiments of Figures 2-4.
  • the RFID radio hardware comprises separate digital and analog hardware 512, 509, which is respectively split between signal processor 504 and discrete (analog) radio device 502. Accordingly, platform 210 may be considered to overlap with hardware abstraction layer 203, as indicated by respective braces 210 and 203.
  • FIG. 6 is a diagram of an exemplary embodiment of the present operating system architecture 600 for an RFID Reader including an integrated application / signal processor 604 and transceiver 602.
  • the system embodiment shown in Figure 6 is especially suitable for highly embedded RFID applications.
  • applications 605, libraries 607 and drivers 609, along with associated APIs reside within a single microcontroller 604 that controls an integrated transceiver 602 (with both analog and digital hardware 610 / 612) or a discrete analog radio (with analog hardware 610 only).
  • Software/firmware modules and drivers 605 / 607 / 609 in integrated signal processor 604 communicate with digital hardware 612 therein, and also with digital hardware 512 in signal processor 504, via APIs, libraries, and drivers 305/306 and 303/304, as described above with respect to the embodiments of Figures 2-4.
  • the RFID radio hardware comprises separate digital and analog hardware, which may be split between signal processor 504 and discrete (analog) radio device 502, as in the system of Figure 5. Accordingly, platform 210 may be considered to overlap with part of framework 201 , as indicated by respective braces 210 and 201.
  • FIG. 7 is a diagram of an exemplary embodiment of the present operating system architecture showing modularity and selectively of security with respect to the software and firmware components of a reader 700.
  • layers 203, 205, and 207 i.e., all layers of framework 201 have been integrated into an RFID reader.
  • the software/firmware in reader 700 includes proprietary source code (and other information) security capability, as well as secure delivery capability, so that a user can encapsulate code into a software module that may be distributed in a secure manner (i.e., without being copied).
  • proprietary source code and other information
  • secure delivery capability so that a user can encapsulate code into a software module that may be distributed in a secure manner (i.e., without being copied).
  • selected code in software or firmware form
  • the present system architecture allows any specific software/firmware module to have its API known / published, but any module containing API-related code (the code accessed by the API), for example, may remain protected and secure. Other parties can make function calls to the protected functions by making calls to the functions' published APIs.
  • Each of the components within framework 201 is selectively securable at three levels, i.e., at the driver, libraries, API and/or application level. Some components may be open source, and other components may be locked and proprietary so that third parties can use this open architecture framework as a secure delivery vehicle for their code into the market.
  • module 702 in application layer 207 modules 712 and 714 in hardware abstraction layer 203, and modules 722 and 726 in application software interface layer 205 are encrypted so that they remain inaccessible to unauthorized users and other third parties.
  • FIG. 8 is a flowchart showing an exemplary set of steps performed in the initial setup of one embodiment of the present system.
  • application code for an RFID reader is first written; this establishes the desired new functionality.
  • the application makes function calls to library functions in sub-layer 305 of layer 205 (shown in Figure 3A) using particular APIs in sub-layer 306 of layer 205. Since each function is a modular software component, the application may selectively call any of the total available functions. Based on which functions are called by the application, at step 810, only those functions which are called are included, at step 815, for compilation into object code, which is performed at step 820.
  • FIG. 9 is a flowchart showing an exemplary set of steps performed in operation of one embodiment of the present system.
  • an application in layer 207 calls Library layer API 306(23) in vertical framework sub-layer 306 of layer 205 to read the contents of an RFID tag 230, for example.
  • library layer API 306(23) calls 'Read Tag 1 function 305(23) in framework layer 305 / firmware stratum Level 335, sub-level 23 in API Library 305.
  • the 'Read Tag” function 305(23) is shown in Table 1 under the "Fig. 3 Level” heading 335, "Radio Communication Control", at sub-level 33.
  • Steps 905 and 910 of the present example are indicated by arrow 315 in the 'Reader Communication & Control' callout in Figure 3B.
  • the 'Read Tag 1 library function 305(23) calls
  • Read Tag driver API 304(23) calls Read Tag driver 303(23) in driver layer 203, in framework layer 305 / firmware stratum Level 335, sub-level 23 .
  • Steps 915 and 920 of the present example are indicated by arrow 313 in Figure 3B.
  • the Read Tag driver sends a Read Tag command to platform 210, as indicated by arrow 204.
  • the platform sends the Read Tag command to Tag 230, which reads information stored in the tag, and sends information back to the reader, as indicated by arrow 202 in Figure 3B.
  • steps 910 through 925 in the present example are each performed by a module in the same firmware stratum level (i.e., Level 335, sub-level 23).

Landscapes

  • Engineering & Computer Science (AREA)
  • Artificial Intelligence (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Near-Field Transmission Systems (AREA)
  • Stored Programmes (AREA)
  • Radar Systems Or Details Thereof (AREA)
  • Transceivers (AREA)

Abstract

La présente invention concerne une structure cadre servant à commander un dispositif RFID comportant une plate-forme comprenant une radio RFID. La structure comprend un cadre en couches composé d'une première couche, comportant au moins un module fonctionnel comprenant un lecteur de dispositif, couplée de manière qu'elle puisse communiquer avec la plate-forme; et d'une deuxième couche, comportant au moins un module fonctionnel comprenant une interface API, couplée de manière qu'elle puisse communiquer avec la première couche et avec une application de commande de dispositif RFID.
EP06750968A 2005-04-21 2006-04-21 Systeme de fonctionnement d'un lecteur rfid et structure associee Withdrawn EP1872598A4 (fr)

Applications Claiming Priority (10)

Application Number Priority Date Filing Date Title
US67369205P 2005-04-21 2005-04-21
US71295705P 2005-08-31 2005-08-31
US11/301,587 US20060238304A1 (en) 2005-04-21 2005-12-13 System and method for adapting an FRID tag reader to its environment
US11/301,396 US20060238302A1 (en) 2005-04-21 2005-12-13 System and method for configuring an RFID reader
US11/301,770 US20060238305A1 (en) 2005-04-21 2005-12-13 Configurable RFID reader
US11/301,423 US20060238303A1 (en) 2005-04-21 2005-12-13 Adaptable RFID reader
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
US11/387,421 US7659819B2 (en) 2005-04-21 2006-03-23 RFID reader operating system and associated architecture
PCT/US2006/015094 WO2006116086A2 (fr) 2005-04-21 2006-04-21 Systeme de fonctionnement d'un lecteur rfid et structure associee

Publications (2)

Publication Number Publication Date
EP1872598A2 true EP1872598A2 (fr) 2008-01-02
EP1872598A4 EP1872598A4 (fr) 2009-09-09

Family

ID=37215271

Family Applications (2)

Application Number Title Priority Date Filing Date
EP06750968A Withdrawn EP1872598A4 (fr) 2005-04-21 2006-04-21 Systeme de fonctionnement d'un lecteur rfid et structure associee
EP06750888A Withdrawn EP1872597A2 (fr) 2005-04-21 2006-04-21 Lecteur rfid et emetteur-recepteur rf combines

Family Applications After (1)

Application Number Title Priority Date Filing Date
EP06750888A Withdrawn EP1872597A2 (fr) 2005-04-21 2006-04-21 Lecteur rfid et emetteur-recepteur rf combines

Country Status (2)

Country Link
EP (2) EP1872598A4 (fr)
WO (2) WO2006116086A2 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2967802B1 (fr) * 2010-11-22 2012-11-23 Inside Contactless Dispositif de radiocommunication gsm comprenant un lecteur d'etiquette uhf

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6078251A (en) * 1996-03-27 2000-06-20 Intermec Ip Corporation Integrated multi-meter and wireless communication link
WO1999057649A2 (fr) * 1998-05-04 1999-11-11 Intermec Ip Corporation Dispositif de collecte automatique de donnees comportant une fonction de communication par reseau
US6420961B1 (en) * 1998-05-14 2002-07-16 Micron Technology, Inc. Wireless communication systems, interfacing devices, communication methods, methods of interfacing with an interrogator, and methods of operating an interrogator
EP1516450A4 (fr) * 2002-06-26 2008-09-17 Nokia Corp Station de lecture/ecriture d'etiquette r.f. a base bluetooth r.f.

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
CHOPPY C ET AL: "Architectural patterns for problem frames - Relating software requirements and architectures" IEE PROCEEDINGS: SOFTWARE, IEE, STEVENAGE, GB, vol. 152, no. 4, 5 August 2005 (2005-08-05), pages 198-208, XP006024952 ISSN: 1462-5970 *
FUJITA M ET AL: "A reconfigurable robot platform" ROBOTICS AND AUTONOMOUS SYSTEMS, ELSEVIER SCIENCE PUBLISHERS, AMSTERDAM, NL, vol. 29, no. 2-3, 30 November 1999 (1999-11-30), pages 119-132, XP004218279 ISSN: 0921-8890 *
MCGREGOR G ET AL: "A hardware/software co-design environment for reconfigurable logic systems" FIELD-PROGRAMMABLE LOGIC AND APPLICATIONS. FROM FPGAS TO COMPUTING PARADIGM. 8TH INTERNATIONAL WORKSHOP, FPL'98. PROCEEDINGS SPRINGER-VERLAG BERLIN, GERMANY, 1998, pages 258-267, XP002539079 ISBN: 3-540-64948-4 *
See also references of WO2006116086A2 *

Also Published As

Publication number Publication date
EP1872598A4 (fr) 2009-09-09
EP1872597A2 (fr) 2008-01-02
WO2006116086A3 (fr) 2008-11-20
WO2006116012A3 (fr) 2009-04-30
WO2006116086A2 (fr) 2006-11-02
WO2006116012A2 (fr) 2006-11-02

Similar Documents

Publication Publication Date Title
US7659819B2 (en) RFID reader operating system and associated architecture
US7962096B2 (en) System and method for a RFID transponder file system
US20070067325A1 (en) Methods and apparatus to load and run software programs in data collection devices
KR101597199B1 (ko) 각종 판독 범위를 갖는 ｒｆｉｄ 태그들을 구비한 ｒｆｉｄ 포털 시스템
US7522050B2 (en) System and method of RFID device management
US7663486B2 (en) RFID tag user memory indication
US7394379B2 (en) Unique method for embedding business process into RFID grid
CN102710298A (zh) 用于检测不同的近场通信适配器并与其进行通信的系统和方法
US9824246B2 (en) Radio frequency identification tag having input device
KR20060102078A (ko) 무선 주파수 식별을 이용한 선체 블록 관리 시스템
CN111788581B (zh) 使多种形式rfid技术交互以提供附加信息、安全性和性能的设备和方法
EP1872598A2 (fr) Systeme de fonctionnement d'un lecteur rfid et structure associee
Kumar et al. Zigbee based indoor campus inventory tracking using RFID module
US20100156601A1 (en) LLRP-Based Flexible Reader System And Method
Ferreira et al. Prototype for Consultation Cloud IoT Supported Medical Records on RFID Technology
KR101132914B1 (ko) Ｒｆｉｄ용 미들웨어가 탑재된 모바일 단말기
CA2522931C (fr) Systeme et methode pour systeme de fichiers de transpondeur rfid
JP4432148B2 (ja) 送受信装置
KR20140079536A (ko) 입력장치를 갖는 무선식별 태그
WO2006054318A2 (fr) Procede unique d'incorporation d'un processus commercial et d'une intelligence de processus commercial dans un reseau rfid
Aboulouz et al. RFIDMania extensible and adaptable RFID middleware and specifications
SHAIKH et al. RFID BASED SMART OFFICE
KR20100037315A (ko) 알에프아이디 통합 관리 시스템
Swärd Godshantering med Scania Interactor
JP2003050976A (ja) データ処理方法、データ処理装置及びプログラム

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: 20071109

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

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: SKYETEK, INC.

RIN1 Information on inventor provided before grant (corrected)

Inventor name: LOVING, SEAN, T.

DAX Request for extension of the european patent (deleted)
R17D Deferred search report published (corrected)

Effective date: 20081120

RIC1 Information provided on ipc code assigned before grant

Ipc: G06F 9/44 20060101AFI20090729BHEP

A4 Supplementary search report drawn up and despatched

Effective date: 20090807

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: 20091103