U.S. patent application number 11/766588 was filed with the patent office on 2008-02-21 for virtual rfid-based tag sensor.
This patent application is currently assigned to SKYETEK, INC.. Invention is credited to Sayan Chakraborty, Brian McKinney.
Application Number | 20080042830 11/766588 |
Document ID | / |
Family ID | 39731554 |
Filed Date | 2008-02-21 |
United States Patent
Application |
20080042830 |
Kind Code |
A1 |
Chakraborty; Sayan ; et
al. |
February 21, 2008 |
VIRTUAL RFID-BASED TAG SENSOR
Abstract
A method for implementing a virtual sensor in an RFID tag
reading system, including an RFID reader and at least one RFID tag
having tag memory in which sensor data is stored. Initially, sensor
data is read from the tag memory. The sensor data is then stored in
sensor cache memory in the reader. Sensor data is accordingly read
and stored at a predetermined interval. The sensor data in sensor
cache memory is periodically updated, via predictive modeling
software stored in and executed by the reader, to determine a
present or future estimated value for the sensor data from observed
changes in the data.
Inventors: |
Chakraborty; Sayan; (Niwot,
CO) ; McKinney; Brian; (Lakewood, CO) |
Correspondence
Address: |
LATHROP & GAGE LC
4845 PEARL EAST CIRCLE
SUITE 300
BOULDER
CO
80301
US
|
Assignee: |
SKYETEK, INC.
11030 Circle Point Road Suite 300
Westminster
CO
80020
|
Family ID: |
39731554 |
Appl. No.: |
11/766588 |
Filed: |
June 21, 2007 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
11323214 |
Dec 30, 2005 |
|
|
|
11766588 |
Jun 21, 2007 |
|
|
|
Current U.S.
Class: |
340/540 |
Current CPC
Class: |
G06K 7/0008 20130101;
G08B 31/00 20130101; G06K 19/0717 20130101; G08B 21/14
20130101 |
Class at
Publication: |
340/540 |
International
Class: |
G08B 21/00 20060101
G08B021/00 |
Claims
1. A method for implementing a virtual sensor in an RFID tag
reading system including an RFID reader and at least one RFID tag
including tag memory in which sensor data, read from a sensor, is
stored, the method comprising: (a) reading the sensor data from the
tag memory; (b) storing the sensor data in sensor cache memory in
the reader; (c) repeating steps (a) and (b) at a predetermined
interval; and (d) periodically updating the sensor data in the
sensor cache memory, via predictive modeling software stored in and
executed by the reader, to determine an estimated value for the
sensor data from observed changes in the data.
2. The method of claim 1, wherein the RFID tag samples a sensor at
a predetermined rate and accordingly updates, in the tag memory,
the sensor data thus sampled.
3. The method of claim 2, wherein the step of periodically updating
the sensor data in the sensor cache includes collecting trending
data, comprising multiple time-stamped samples of sensor data, to
determine a present estimated value for the sensor data.
4. The method of claim 3, wherein the interval in step (c) is based
on the trending data.
5. The method of claim 1, wherein the RFID tag samples the sensor
at a modifiable rate based on a rate-of-change analysis of the
sensor data, and accordingly updates, in the tag memory, the sensor
data thus sampled.
6. The method of claim 2, wherein the step of periodically updating
the sensor data in the sensor cache includes collecting trending
data, comprising multiple time-stamped samples of the sensor data,
to determine a present estimated value for the sensor data and a
rate of change of the sensor data.
7. The system of claim 1, including providing the sensor data,
stored in the sensor cache memory, to a requesting entity, without
again reading the sensor data presently stored in the tag.
8. The method of claim 1, wherein the reader sends, to a tag
processing system, the data updated in the sensor cache, without
again reading the sensor data presently stored in the tag.
9. The method of claim 1, wherein the sensor data stored in the
sensor cache includes data associated with the tag, but not stored
thereon.
10. The method of claim 1, including: determining that the tag is
moving toward a second RFID reader; and sending the second reader
at least part of the sensor data stored in sensor cache in advance
of the tag's arrival at the second reader.
11. The method of claim 1, wherein the estimated value for the
sensor data is a present estimated value.
12. The method of claim 1, wherein the estimated value for the
sensor data is a future estimated value.
13. The method of claim 1, wherein the estimated value for the
sensor data is a mathematical model based on outputs of multiple
sensors presented as the output of a single simulated sensor.
14. A method for implementing a virtual sensor in an RFID tag
reading system including an RFID reader and at least one RFID tag
including tag memory in which sensor data, read from a sensor, is
stored, the method comprising: (a) periodically sampling sensor
data and storing the data in the tag memory; (b) reading the sensor
data from the tag memory; (c) storing the data thus read in sensor
cache memory in the reader; (d) periodically updating sensor data
in the sensor cache memory using a predictive modeling technique;
(e) after a delay period has expired, again reading sensor data
stored in the tag memory; and (f) repeating steps (b) through (e)
at a predetermined interval.
15. The method of claim 14, including: determining that the tag is
moving toward a second RFID reader; and sending the second reader
at least part of the sensor data in the sensor cache in advance of
the tag's arrival at the second reader.
16. The method of claim 14, wherein the step of periodically
updating the sensor data in the sensor cache includes: collecting
trending data, comprising multiple time-stamped samples of sensor
data, to determine a future estimated value for the sensor
data.
17. The system of claim 16, including providing the future
estimated value to a requesting entity, without again reading the
sensor data presently stored in the tag.
18. The method of claim 14, wherein the reader sends, to a tag
processing system, the data updated in the sensor cache, without
again reading the sensor data presently stored in the tag.
19. The method of claim 4, wherein the RFID tag samples a sensor at
a modifiable rate based on a rate-of-change analysis of the sensor
data, and accordingly updates, in the tag memory, the sensor data
thus sampled.
20. The method of claim 19, wherein the step of periodically
updating the sensor data in the sensor cache includes collecting
trending data, comprising multiple time-stamped samples of the
sensor data, to determine a present estimated value for the sensor
data as well as a rate of change of that data.
21. The method of claim 1, wherein the estimated value for the
sensor data is a mathematical model based on the outputs of
multiple sensors presented as the output of a single simulated
sensor.
22. A method for implementing a virtual sensor in an RFID tag
reading system including an RFID reader and a plurality of RFID
tags, each of which periodically samples an associated sensor and
stores sensor data thus sampled in a respective RFID tag memory,
the method comprising: systematizing the plurality of RFID tags to
form a grid; reading the sensor data from the tag memory in each of
the tags in the grid; storing the sensor data thus read in sensor
cache memory in the reader; and periodically updating the sensor
data in the sensor cache memory, using a predictive modeling
technique, to determine an estimated value for the sensor data from
observed changes in the data read from the sensors.
23. The method of claim 22, wherein the estimated value for the
sensor data is a present estimated value, calculated without again
reading the sensor data presently stored in the tag.
24. The method of claim 22, wherein the estimated value for the
sensor data is a future estimated value, calculated without again
reading the sensor data presently stored in the tag.
25. The method of claim 22, wherein the RFID tag samples the sensor
at a modifiable rate based on a rate-of-change analysis of the
sensor data, and accordingly updates, in the tag memory, the sensor
data thus sampled.
26. The method of claim 25, wherein the step of periodically
updating the sensor data in the sensor cache includes collecting
trending data, comprising multiple time-stamped samples of the
sensor data, to determine a present estimated value for the sensor
data and a rate of change of the sensor data.
27. The method of claim 22, wherein the sensor data is read from
the tag memory is based on the trending data.
28. The method of claim 22, wherein the estimated value for the
sensor data is a mathematical model based on the outputs of
multiple sensors presented as the output of a single simulated
sensor
29. The method of claim 22, wherein the step of periodically
updating the sensor data in the sensor cache includes: collecting
trending data, comprising multiple time-stamped samples of sensor
data, to determine a future estimated value for the sensor data;
generating a sensor data map indicating the location of each said
sensor in the grid and the sensor data associated therewith; and
extrapolating the sensor data in the map, using the trending data,
to indicate a future state of sensor data relative to the sensor
grid.
30. A system for implementing a virtual sensor in an RFID tag
reading system including an RFID tag that periodically samples a
sensor and stores sampled sensor data in tag memory, the system
comprising: an RFID reader including cache memory; and predictive
modeling software stored in the reader; wherein the sensor data is:
read from the memory of the RFID tag by the reader; stored in the
cache memory in the reader; and periodically updated in the cache
memory, using the predictive modeling software executed by the
reader.
31. The system of claim 30, wherein the tag reading system includes
a plurality of RFID tags, each of which periodically samples an
associated sensor and stores sensor data thus sampled in a
respective RFID tag memory, the system further including: trending
data, stored in the cache memory, comprising multiple time-stamped
samples of the sensor data; and a sensor data map, stored in the
cache memory, indicating the location of each said sensor in the
system and the sensor data associated therewith; wherein estimated
future values for the sensor data stored in the sensor data map are
determined by the predictive modeling software using the trending
data.
Description
RELATED APPLICATIONS
[0001] This application is a continuation-in-part of U.S. patent
application Ser. No. 11/323,214, titled "System And Method For
Implementing Virtual RFID Tags", filed Dec. 30, 2005.
BACKGROUND
[0002] 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 transponders 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.
[0003] A basic RFID system includes a transceiver (a reader or
`interrogator`) and a transponder (RF tag) electronically
programmed with unique identifying information. Both the
transceiver and transponder have one or more antennas, which
respectively emit and receive radio signals to activate the tag and
read and write data to it. An antenna is a feature that is present
in both readers and tags, essential for the communication between
the two. An RFID system requires, in addition to tags, a means of
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. Often the antenna is packaged with
the transceiver and decoder to become a reader (an `interrogator`),
which can be configured either as a handheld or a fixed-mount
device. The reader emits radio waves in ranges of anywhere from
contact to 100 feet or more, depending upon its power output and
the radio frequency used. When 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.
[0004] Two methods distinguish and categorize RFID systems, one
based upon close proximity electromagnetic or inductive coupling,
and one based upon propagating electromagnetic waves. While the
term `antenna` is generally considered more appropriate for
propagating systems, it is also applied to inductive systems.
Transponders/Tags
[0005] 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, an external dipole, or utilizing `coil-on-chip`
technology, for data transfer and power generation, where the coil
or dipole acts as an antenna matched to the frequency
supported.
Basic Features of an RFID Transponder
[0006] The transponder includes memory which may comprise read-only
(ROM), random access (RAM) or non-volatile programmable memory for
data storage, depending upon the type of the device. ROM-based
memory is used to accommodate security data and the transponder
operating system instructions which, in conjunction with the
processor or processing logic, deals with the internal
`house-keeping` functions such as response delay timing, data flow
control and power supply switching. RAM-based memory is used to
facilitate temporary data storage during transponder interrogation
and response.
[0007] Non-volatile programmable memory may take various forms,
electrically erasable programmable read only memory (EEPROM) being
typical. This type of memory is used to store the transponder data
and needs to be non-volatile to ensure that the tag data is
retained when the device is in its quiescent or power-saving
`sleep` state or when the tag is not powered on.
[0008] Data buffers are further components of memory, used to
temporarily hold incoming data following demodulation and outgoing
data for modulation and interface with the transponder antenna.
Interface circuitry provides the facility to direct and accommodate
the interrogation field energy for powering purposes in passive
transponders and triggering of the transponder response. The
transponder antenna is the mechanism by which the device senses the
interrogating field and also serves to transmit the transponder
response to interrogation.
[0009] RFID tags come in a wide variety of shapes and sizes. Animal
tracking tags, inserted beneath the skin, can be as small as a
pencil lead in diameter and 10 millimeters in length. Tags can be
manufactured in many different shapes, including credit-card form
factors for use in access applications. The anti-theft hard plastic
tags attached to merchandise in stores are RFID tags. In addition,
heavy-duty transponders are used to track intermodal containers,
heavy machinery, trucks, and railroad cars for maintenance and
other applications.
Powering Tags
[0010] Tags require power to work, even though the power levels
required for operation are invariably very small (microwatts to
milliwatts). RFID tags are categorized as active, passive, or
semi-active/semi-passive, the designation being determined by the
manner in which the device derives its power.
[0011] Active RFID tags are powered by an internal battery and are
typically read/write devices, i.e., tag data can be rewritten
and/or modified. An active tag's memory size varies according to
application requirements; some systems operate with up to 1 MB of
memory. In a typical read/write RFID work-in-process system, a tag
might give a machine a set of instructions, and the machine would
then report its performance to the tag. This encoded data then
becomes part of the tagged part's history. The battery-supplied
power of an active tag generally gives it a longer read range. The
trade-off is greater size, greater cost, and a limited operational
life (which may yield a lifetime of 10 years, depending upon
operating temperatures and battery type).
[0012] In general terms, active transponders allow greater
communication range than can be expected for passive devices,
better noise immunity and higher data transmissions rates when used
to power a higher frequency response mode.
[0013] Passive tags operate without an internal battery source,
deriving the power to operate from the field generated by the
reader. Passive tags are consequently much lighter than active
tags, less expensive, and offer a virtually unlimited operational
lifetime. The trade-off is that they have shorter read ranges than
active tags and require a higher-powered reader. Passive tags are
also constrained in their capacity to store data and the ability to
perform well in electromagnetically noisy environments. A passive
tag must typically be powered without interruption, and storing a
lot of data on a tag is subject to difficulty in reliably writing
and reading that data to and from the tag. Sensitivity and
orientation performance may also be constrained by the limitation
on available power. Despite these limitations, passive transponders
offer advantages in terms of cost and longevity.
[0014] Semi-active/semi-passive tags use a battery to assist the
interrogator, but otherwise operate as a passive tag (e.g., in
response to a field from a reader). They offer performance between
that of a passive tag and that of an active tag in terms of size,
range, lifetime, and cost.
Data Carrying Options
[0015] Data stored in data carriers invariable require some
organization and additions, such as data identifiers and error
detection bits, to satisfy recovery needs. This process is often
referred to as source encoding. Standard numbering systems, such as
UCC/EPC and associated data defining elements may also be applied
to data stored in tags. The amount of data is
application-dependent. Basically, tags may be used to carry drug
pedigrees, manifests, product identification information, etc., as
well as: [0016] identifiers, in which a numeric or alphanumeric
string is stored for identification purposes or as an access key to
data stored elsewhere in a computer or information management
system, and/or [0017] portable data files, in which information can
be organized, for communication or as a means of initiating actions
without recourse to, or in combination with, data stored
elsewhere.
[0018] In terms of data capacity, tags can be obtained that satisfy
needs from single bit to kilobits. The single bit devices are
essentially for surveillance purposes. Retail electronic article
surveillance (EAS) is the typical application for such devices,
being used to activate an alarm when detected in the interrogating
field. They may also be used in counting applications.
[0019] Tag devices characterized by data storage capacities up to
128 bits are sufficient to hold a serial or identification number
together, possibly, with parity check bits. Such devices may be
manufacturer or user programmable. Tags with data storage
capacities up to 512 bits are invariably user programmable, and
suitable for accommodating identification and other specific data
such as serial numbers, package content, key process instructions
or possibly results of earlier interrogation/response
transactions.
[0020] Tags characterized by data storage capacities of around 4
kilobits or larger may be regarded as carriers for portable data
files. With increased capacity the facility can also be provided
for organizing data into fields or pages that may be selectively
interrogated during the reading process.
Data Programming Options
[0021] Depending upon the type of memory a tag contains the data
carried may be read-only, write once read many (WORM) or
read/write. Read-only tags are invariably low capacity devices
programmed at source, usually with an identification number. WORM
devices are user programmable devices. Read/write devices are also
user-programmable but allow the user to change at least some of the
data stored in a tag. Many tags have both read-only and read-write
memory sections. Portable programmers (interrogators) may be
recognized that also allow in-field programming of the tag while
attached to the item being identified or accompanied.
The Reader/Interrogator
[0022] 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`. 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.
[0023] For some applications, various types of sensors
(temperature, shock, humidity, etc) are connected to tags. For
example, several types of RFID tags have integrated temperature
sensors. Heretofore, temperature data read by a tag has been
treated as just data on the tag. In many cases, frequent sampling
of the sensor is required. Previous RFID systems require that a tag
be in the field of the reader (interrogator), and powered on, in
order for the user to interact with it. Thus, every time a sensor
reading is taken, the reader and tag must be powered on, causing
additional consumption of power by the reader and the tag. It is
thus desirable to minimize this power consumption problem
associated with the frequent reading of RFID tag sensors.
SUMMARY
[0024] A method is disclosed for implementing a virtual sensor in
an RFID tag reading system which includes an RFID reader and at
least one RFID tag having tag memory in which sensor data is
stored. In one embodiment, sensor data is initially read from the
tag memory. The sensor data is then stored in sensor cache memory
in the reader. Sensor data is accordingly read and stored at a
predetermined interval. The sensor data in sensor cache memory is
periodically updated, via predictive modeling software stored in,
and executed by, the reader, to determine a present or future
estimated value for the sensor data from observed changes in the
data. Requests for sensor data are served from the cache memory
instead of from the sensor itself.
BRIEF DESCRIPTION OF THE DRAWINGS
[0025] FIG. 1A is a diagram of an exemplary embodiment of the
present system for implementing virtual RFID tag sensors;
[0026] FIG. 1B is an exemplary diagram of cache memory used in one
embodiment of the present system;
[0027] FIG. 1C is an exemplary diagram of cache memory in one
embodiment of the present system, including trending data and a
spatial map;
[0028] FIG. 2 is a flowchart showing an exemplary set of steps
performed in operation of one embodiment of the present system;
[0029] FIG. 3 is a flowchart showing an exemplary set of steps
performed in managing cache memory;
[0030] FIG. 4 is a flowchart showing an exemplary set of steps
performed in adding additional data to a tag;
[0031] FIG. 5 is a flowchart showing an exemplary set of steps
performed in handling tag sensor data, and
[0032] FIG. 6 is a flowchart showing an exemplary set of steps
performed in updating sensor data in sensor cache.
DETAILED DESCRIPTION
[0033] The present RFID tag reading system maintains a cache entry,
which includes locally-updated data for tags that a tag reader has
read in a given period. The system allows upstream readers or users
to interact with the cache entries rather than with the tags
themselves. This process optimizes power use for the tag and the
tag reader by significantly reducing the number of tag read
commands that must be issued for reading data from sensors attached
to the tags. The process also allows upstream users to operate with
minimum latency between a request for sensor data and a response.
Rather than constantly sampling the sensors, an RFID tag reader
maintains values and trending, using predictive data, in the
reader's cache memory.
[0034] Because users interact with the data associated with the
tag, instead of the tag itself, tag sensor data needs to be read
only once and is then stored for later reference. This frees the
system from requiring the tag to always be `in-field` (within range
of a reader) and powered on, thus providing for faster response,
greater reliability, and lower power consumption. FIG. 1A is a
diagram of an exemplary embodiment of the present system for
reading RFID tags. As shown in FIG. 1A, the system comprises one or
more RFID receiver/interrogators 102* (hereinafter simply called
`readers`) for reading tags 101, each including one or more cache
memories 103 for storing data associated with various tags, and at
least one tag processing system 104. As used herein, an asterisk in
parentheses following a reference number indicates an arbitrary one
of the type of entity designated by the reference number. The
present system may also include one or more intermediate servers
105 to provide for communication between readers 102* and between
readers 102* and the tag processing system 104.
[0035] As shown in FIG. 1A, in an exemplary embodiment, readers
102* are communicatively coupled in a network via any networking
mechanism, such as the Internet 150, or via cable or wireless means
131,138.
[0036] In one embodiment, data initially received from a tag sensor
160(*) and stored in tag memory 152 may be stored in sensor cache
memory 103(S*) in a requesting reader, e.g., reader 102(1). Sensor
cache memory 103(S) is described in detail below with respect to
FIG. 5. Sensors 160(*) may be part of, or connected directly
(hardwired) to a tag 101(*) [e.g., sensors 160(1)-160(3)], or
wirelessly connected to a tag 101(*) [e.g., sensor 160(n)].
[0037] Each reader 102* includes code 109 which implements the
functions performed by the reader, as described herein. Code 109
may comprise software (executed by a processor), firmware, or a
combination of both. Tag cache memory 103 [which may function as
sensor cache memory 103(S*)] is associated with each reader 102*,
and may be either local to a reader [e.g., tag cache 103(L)], or
located remotely with respect to a reader [e.g., tag cache 103(R)]
and connected to the reader via any suitable communications link
131, 138. Tag cache memory 103 may also be co-located with
server(s) 105 and/or tag processing system 104. Individual
per-reader tag caches can together be considered one large tag
cache 103 with potentially duplicate entries.
[0038] Tag cache 103 can be any kind of memory for storing tag
information. In an exemplary embodiment, cache 103 comprises a
basic in-memory data structure (hash table, tree, or other
structure) indexed by the tag ID. The particular structure of a
particular tag cache 103 is a function of the format (and other
properties) of the tag IDs being used.
[0039] FIG. 1B is a diagram of an exemplary embodiment of tag cache
memory 103 used by the present system. As shown in FIG. 1B, tag
cache memory 103 contains data structures including a tag index
111, a cache entry buffer 133, commit buffers 110(1)/110(2), a
command/script queue 140, and lists 112/135 which are used to
determine least-recently-used (LRU) tag data, for cache management
purposes. The data structures shown in FIG. 1B are referred to
throughout this description.
[0040] FIG. 2 is a flowchart showing an exemplary set of steps
performed in operation of one embodiment of the present system. As
shown in FIG. 2, at step 205, a reader 102 reads a tag 101, and
stores the tag data in an intermediate buffer (not shown). Data
from the memory of one or more tags of different tag types may be
read and then stored in tag cache 103 along with additional tag
state information. At step 207, if the tag data is compressed, then
the data is decompressed, and if the tag data is encrypted, then
the data is decrypted. Re-compression and/or re-encryption is
performed on appropriate data, if necessary, prior to the data
being sent (back) to a tag in step 225 (described below). If tag
data is to be encrypted, tag cache 103 also includes encryption key
storage.
[0041] At step 210, additional data may be added to, or associated
with, a tag, as described in detail below with respect to FIG. 4.
At step 213, the data for the tag 101 is stored in cache memory
103, as described below with respect to FIG. 3. The remaining steps
shown in FIG. 2 are described further below.
Cache Organization and Management
[0042] In an exemplary embodiment, the present system maintains a
cache entry (in buffer 133) of all the tags it has read in a given
period, including all of the associated tag data, as well as age
since last transaction, which is optional. FIG. 3 is a flowchart
showing an exemplary set of steps performed in managing cache
memory. As shown in FIG. 3 at step 305, after a reader 102 reads a
tag 101, space in cache is found and allocated for tag data &
`housekeeping` data, and the data associated with the tag is then
stored in cache 103. This tag-associated data 123 may be kept
in-line with the cache entry 122 (as shown in FIG. 1B) if the data
is fixed length (all cache entries are preferably, but not
necessarily, the same size). If the tag data is of variable length,
or even if it is fixed size, the data may be stored in memory (in
tag processing system 104) separate from a particular cache 103, to
be managed separately. It should be noted that tag-associated data
123 may include sensor data read by, and initially stored in, an
RFID tag.
[0043] At step 310, each current tag read by a reader 102 and the
data 123 associated therewith is indexed by tag ID (or other
primary key) and stored in tag index 111, which provides a pointer
to the tag stored in cache entry buffer 133 in tag cache 103. Each
time a tag entry is written to in cache 103, it is a candidate to
be flushed from the cache and sent to the actual tag the next time
there is a transmit operation. Thus, a list 110(1)/110(2) of
changed entries is kept. At step 315, a pointer to cache entry is
stored in a `committed` list 110. In one embodiment, this list 110
is an array of pointers 132 kept in one or more buffers. Each time
there is a transmit operation, the system starts at the top of the
list 110(1) in the first buffer, follows the pointer to the cache
entry to get the next value and writes it out to the tag. Once the
tag has ACK-ed receiving the value to be written, the pointer is
removed from the list.
[0044] If the tag is not immediately available, it is kept in the
committed list 110. Any non-ACK'd transmissions are copied to a
`next` section of the committed list 110(2), so that there are two
lists/buffers used for storing for committed transactions: the
`current` list 110(1) and the `next` list 110(2). The `next` list
110(2) is generally empty, but it can be used in the event that
data is being changed in cache 103 while a transmission is
occurring. If a tag does not respond with an `ACK` within a
predetermined time, it is treated as non-existent, and stored for
possible later use.
[0045] Alternative embodiments of the present system may include
any of the following mechanisms and formats, which have been
standardized across all readers 102 and tag caches 103: [0046] a
standardized mechanism for locating a specific sensor with respect
to an interrogator. In the case where the caches 103 of multiple
readers are searched with a search engine, looking for a value
stored on the tag, or stored data about the tag, the matches can be
reported in order of decreasing likelihood of fit, and the user can
then select the best-fit tag--which should also reveal which
interrogator last communicated with it. If the cache 103 itself is
`reader-centric` (showing all tags one reader has seen), finding
all the entries for a given tag across multiple reader tag caches
is `tag-centric`. [0047] a standardized mechanism for reporting the
presence or absence of a sensor with respect to a reader, with the
command embodied as XML fragment, for example: [0048]
<TagPresent epc=''12345abcde/> [0049] a standardized
mechanism for reporting a state change of a sensor with respect to
a reader, with the command embodied as XML fragment, for
example:
[0050] <NotifyOnTagStateChange epc="74087038"
toState="KILLED"/>
Generation Numbers
[0051] In one embodiment, each time a reader 102 reads in one or
more tags associated with the same (multiple) tag read operation,
the tags are stored in cache (if a particular tag is not already
stored there), and conditionally assigned a current generation
number 145 (at step 320). A tag generation number 127 is associated
with each tag that is read. If a tag is already in cache 103, then
if reading it again (i.e., the current tag read operation) is
considered to make the tag `used`, the generation number in the
cache entry is updated to the current generation; otherwise the
generation number is not updated at this time.
[0052] A pointer 142 to each entry 122/123 is stored in the current
LRU chunk 143 for this generation, in LRU list 112, at step 325.
The number of entries in the generation is stored in a master LRU
list 135 along with a pointer 137 to the chunk, at step 330. When
garbage collection (described in detail below) is needed, starting
at the lowest non-zero count entry in the LRU master list 135, each
remaining (non-zero) pointer in the chunk is checked to see if it
has the generation number of the current lowest generation (as it
is possible that none of the entries in the chunk will have it). If
so, that entry is erased from cache 103 and LRU lists 112 and 135.
If there are no current lowest generation number-matching entries
available in the current chunk, the next chunk is examined. It is
an error if no entry can be found that matches the current lowest
generation number known, but a check should be made to prevent
possible anomalous system behavior. Each time a multiple read
operation is completed, the generation number 145 is
incremented.
[0053] When cache memory 103 fills up, LRU list 112 is scanned from
the current `start` point (which may be kept in a separate register
that always points to the last entry that was queried during the
previous LRU cleanup; initially the register points to the first
item). It is `optimistically` assumed that the start pointer is
fairly close to the oldest tag so that it is not necessary to scan
the entire LRU list to find vacant slots. There is also a pointer
to the end of the LRU list, and the start can never pass the end
(and vice versa). The length of the LRU list 112 thus determines
how many tags can be held in memory. In one embodiment, each tag
entry is 4 bytes in length.
Garbage Collection
[0054] Since cache can only grow to a certain size, a method of
removing stale cache entries (`garbage collection`), such as a
simple LRU (least-recently-used) mechanism, is required. The LRU
list 112 itself is a list (or stack) of fixed length entries. Each
entry in LRU list 112 comprises a pointer 142 to its representative
entry 122/123 in cache. These LRU entries 142 may function as 32
bit addresses. Thus, when the LRU list is full, garbage collection
is performed, at step 335. One way to determine when garbage
collection is necessary is to keep a count of the number of free
slots in the LRU list. When the number of free slots is zero, it is
time to `clean up` the LRU list by performing garbage collection,
erasing least-recently used entries in the LRU list. Erasing an LRU
entry may include writing four 0x00 values to the entry.
[0055] In an exemplary embodiment, the garbage collection process
begins by referencing the `start` pointer to determine the
generation number of the associated entry. The first tag with the
lowest generation number is found and then erased. This process
requires that additional data values be kept. The first of these
values is the current lowest generation number associated with
actual cache entries. For each generation number, a count is kept
of the number of tags in the generation. As long as the lowest
generation number still has a count greater then zero, the LRU list
is scanned for that entry. By definition, the entry must be in the
same `chunk` as the one in which it was written when it first
entered the reader. If the pointer to the slot in the LRU list for
the starting point for that particular generation is kept with each
generation index (that has the count), then the start pointer is no
longer required. Instead, the system starts at the beginning of the
generation `chunk` which is stored in the generation count list.
Thus the generation count list now contains both a count and a
pointer to where in memory the chunk is located--this also means
that the chunks themselves need not be contiguous. Once the
generation count is zero, the associated chunk can be deallocated.
As an optimization, below a certain threshold, those remaining
entries can be copied to their currently marked generation. The
chunk block is then re-allocated, and the original entries plus
these leftover entries are copied into one contiguous block.
Queuing
[0056] Tags presently in use must receive commands as they are
issued (and thus must be in-field for the command to work). If
several commands do essentially the same thing (such as writing a
value) but only the last one matters (e.g., a total count),
previous systems require that the tag still be powered up and
written to for each command. The present system allows commands to
be queued in a command/script queue 140 until an unavailable tag is
available (or until some other event occurs), so the user (or the
system) does not have to remember to reissue the commands.
Command/script queue 140 allows several commands to be discarded or
combined and a single command sent that achieves the same final
result as multiple commands. This queuing method saves power,
reduces user interaction, and allows tag mobility.
[0057] In addition to queuing commands, event-triggered scripting
commands may also be stored in command/script queue 140 in cache
103. Commands include requests such as "read location X from tag,
write a value to location Y, and then lock the tag". This can be
viewed as a sequence of standard commands combined in some order
and intended to execute in that order without intervention.
[0058] At step 215 (in FIG. 2), commands intended for the tag, if
any, are queued in command/script queue 140. At step 220, the
queued/scripted commands are executed in response to an event,
based on tag data or EPC/tag ID. Execution of these commands may
include sending tag data 123 back to a tag 101. Events may include
any event or situation that is of interest to a particular system.
For example, a tag with a certain EPC/UID enters a field, the tag
contains a certain value at a certain location, a timer expires, a
certain time is reached, a sensor value exceeds a preset threshold,
an external message is received, etc.
[0059] In one embodiment, a tag command set is embodied as XML via
HTTP. The commands in this command set may be carried as XML
fragments in an HTTP POST. Tag commands may include commands such
as the following: TABLE-US-00001 <ReadTag epc="3829389"
start="0x00" size="0x4"/> <WriteTag epc="deadbeef"
start="0x00"> [Data] </WriteTag> <LockTag epc="decaf"
start="0x03" size="0x4"/> <KillTag epc="abcdef"/>
[0060] Event-driven filter commands may include commands such as:
TABLE-US-00002 <FilterEPCByRegularExpression
ex="(ab|bc|de)?1234"/> <FilterTagContentsByMemoryValue
start="0x4"> [Value] </FilterTagContentsByMemoryValue>
[0061] Command sets may include commands which: [0062] interact
with the actual tags 101 to confirm tag state changes; [0063] lock
all tag interactions to a specific reader 102 and/or cache 103;
[0064] interact with a tag 101 at a minimum polling frequency;
and/or [0065] minimize actual tag interactions until actually
necessary (such as when a tag is about to leave a field).
[0066] Tag interactions may include locating tags by any stored
value in the cache (by searching cache 103) and/or writing data to
tag memory. For example, in a drug pedigree system, the system may
instruct tag cache 103 to write a distribution center's UID to all
tags exiting the building. A container tracking system may write
manifest information to the tags.
[0067] At step 225, the cache entry 122/123 is sent to one or more
intended (target) systems potentially including other readers 102
and/or processing system 104. The present system provides the
capability to allow user interactions with a given tag to be routed
to the correct reader 102. Results are then stored and/or sent to a
user and/or to tag processing system 104, at step 230. A reader 102
may issue a command and flag it such that if the command is not
executed against the tag within a given period of time, then the
command fails.
Tag Cache Exchange
[0068] A reader-to-reader protocol allows readers 102 to request
and exchange cache entries. This process may include determining
that a tag is moving toward another reader 102 (or that a reader is
moving towards that tag) and sending that reader the cache entry in
advance of the tag's arrival at the other reader.
[0069] One or more mechanisms, known in the art, may be employed
for readers to exchange tag cache entries, both with an
intermediate server and peer-to-peer. These tag cache exchange
mechanisms fall into three general categories:
[0070] (1) Push
[0071] Either on an event (such as a tag leaving a reader's field)
or at a regular interval, the reader pushes one or more tag entries
to any readers in a given system or to a central repository, which
can keep entries for all known tags.
[0072] (2) Pull
[0073] Again, event or time based, in this model a reader requests
one or more tag entries (such as when a new tag enters its field)
from other readers or a central repository. One mechanism to
accomplish this is IP multicast carrying the requested tag ID and
an optional maximum age. All entities with an entry for that tag ID
(potentially filtered by the maximum age of the entry) respond with
an ACK, a count of pending global or group operations against the
tag, and a time value representing the last interaction with the
tag. The pulling reader then makes a specific request to the reader
or readers that it wants to get data from in the order in which it
wants to receive the entries (writing each one in succession so
that it ends up with a composite entry). Other readers can listen
and update themselves simultaneously.
[0074] There may be operations (e.g., write) that can take place
anywhere (globally), there may be some operations that must occur
at a specific grouping of readers (such as ones at exit doors) and
some which can only occur at a specific reader and therefore not
offered to the requestor.
[0075] (3) Publish and Subscribe
[0076] A reader may subscribe to any events around a specific tag
ID or condition (e.g., anytime a tag leaves a building). In this
case, readers observing or generating such events may publish cache
entries to the subscribers. This allows a `find me, follow me`
service based on RFID. For example, as a person walks (with a
tag-enabled badge) through the halls of a hospital, readers are
updated with the person's cache entry as the person enters the
readers' fields. Tracking the cache requesters versus a spatial map
of installed readers provides an effective trajectory. The cache
entries will accumulate all the pending activities that would
otherwise be missed by walking too fast, but when the person stops,
the local reader updates the tag as needed, while simultaneously
updating the person's location.
Background Process
[0077] It is also possible to exchange cache entries as a
background process, instead of, or in addition to, the methods
described above. This exchange process is typically implemented as
a `blanket` push. In this mode, readers are constantly exchanging
cache entries when they have processor or communications bandwidth
to do so. As a result, all caches become more or less equivalent
over time.
Tag Cache Exchange Protocol
[0078] In one embodiment, the present system includes a
transport-independent protocol for tag caches 103 to interact with
each other. An example protocol command set embodied as XML
fragments is set forth below:
[0079] Query: TABLE-US-00003 <ContainsTagByEPC epc="123456"/>
<SendTagsSeenAfter time="23:45:12T12052005MST"/>
Alerts/Notification:
[0080] <NotifyOnEPCRegularExpression
ex="gsn:[0-9]{5}[A-Za-z]{5}"/>
[0081] In one embodiment, the present system employs a standardized
format for the exchange of tag cache entries, with the command
embodied as XML fragment, for example:
[0082] <SendTagsSeenAfter time="23:45:12T12052005MST"/>
[0083] A standardized format for the exchange of queued commands
may also be employed, with the command embodied as XML fragment,
for example:
[0084] <QueryPendingOps epc="2382938039843"/>
Virtual Tags
[0085] RFID tags presently in use are limited to the capabilities
inherent in the tag. In multiple tag environments, previous systems
are typically forced to use the common subset of tag capabilities,
and have limited ability to support new, enhanced tags. The present
system provides a `virtual tag` in cache memory, which can provide
a superset of the capabilities of a given tag by simulating common
capabilities. A virtual tag, comprising data stored in one or more
tag caches 103, for example, tag caches 103(L) and 103(R), can
simulate a memory area larger than that physically present on the
tag in several different ways.
[0086] In an exemplary embodiment, tag cache entries have a
canonical format (i.e., a virtual tag format) that provides a
superset (or subset) of the capabilities of the tags and tag types
supported. For example, a virtual Tag may have more memory, finer
access controls, more or different security features, exhibit
"always on" and "always connected" behaviors, and/or faster
read/write rates than a corresponding physical tag.
[0087] Example of a Virtual Tag: TABLE-US-00004 struct VirtualTag{
unsigned char EPC/UID[64]; time_t TimeLastSeen time_t TimeFirstSeen
acl_t *ACLs; unsigned char Memory[1024]; tag_operation_t
*PendingOperations; }
[0088] In one embodiment, the canonical format of the tag cache
entries includes support for writing an off-tag data storage
location [e.g., URL, database location, and optionally a
confirmation or authentication value (e.g., a hash)] to the tag,
rather than the data itself.
[0089] A virtual tag can be employed to store a reference 151 (such
as a URL) to the data on the tag (real tags can store a reference
as well), where the actual data (which may be too large to fit into
tag memory) is stored in another location. FIG. 4 is a flowchart
showing an exemplary set of steps performed in adding additional
data for a tag 101, or replacing existing tag data. As shown in
FIG. 4, at step 405, data (which may be too large to fit into tag
memory) is stored in an entity separate from the tag itself, such
as in a file or database in tag processing system 104, to be
located using a reference 151 to be stored on the tag. At step 410,
additional or replacement data is written to a tag 101 and stored
on the tag. This data may include a reference 151 such as a URL, or
a reference to the actual data itself.
[0090] An optional confirmation value (typically a hash) can also
be stored on a tag 101, as indicated by step 415. This allows the
tag cache (typically hidden from the user) to verify that the
stored data is the correct and up-to-date data on the tag, without
reading all of the data on the tag.
[0091] In operation, the tag 101 is read and the reference 151
stored on the tag is retrieved, at step 420. Then, at step 425, the
file or other entity is accessed via the reference 151 stored on
the tag.
Virtual Sensor
[0092] A virtual sensor can be created that provides a data value
at a different rate than that actually provided by the real sensor,
using mathematical techniques such as interpolation, extrapolation,
averaging, etc.
[0093] Another type of virtual sensor can be created that combines
the outputs of one or more actual sensors to simulate a sensor
which does not exist (such as combining the outputs of a
temperature sensor and a pressure sensor to estimate humidity, even
though a humidity sensor is not available).
Individual Tag Web Pages
[0094] A web-enabled reader, e.g., reader 102(1) connected to the
Internet 150 (as shown in FIG. 1A), allows access to individual
tags 101 by publishing per-tag web pages. These web pages present
tag data and allow changes to that data via familiar web controls.
The web page to be accessed may present a password dialog to
require users to log in to the tag to perform operations. The web
page can be exported as XML via a service such as RSS to provide a
simple machine interface to the tag.
[0095] Tags 101 are not always powered on and connected to a
tag-reading system--passive tags are only on and connected when an
interrogator is powering them, and active tags `sleep` to conserve
their battery when not being accessed. However, the Internet and
enterprise infrastructure are most commonly connected and `always
on` (such as in the case of internal and external IP networks),
with connected devices able to be located easily. The present
system allows the tag cache to act like an always-on device and
connected proxy for the tag itself, allowing existing networks to
seamlessly work with what appears to each as the tag itself. In
this way, a chair, for example, could be connected to the internet
simply via a tag placed on it. In this example, cache 103 presents
a web page for the chair, and the web page may be visited,
examining data items such as the chair type, what room it is in,
and who is sitting in it (if the person is wearing a badge
containing a tag). This allows essentially anything to be connected
to the internet via an inexpensive tag (e.g., a tag costing less
than 20 cents). Cache 103 may also sustain a secure synchronous
connection (such as SSL) on behalf of the tag.
[0096] In one embodiment, SSL protocol from a web browser to a tag
reader can be combined with secure tag protocols (e.g., Philips
MIFARE or DesFire) to create seamless security from web browser to
tag. The binding can be strengthened between the protocols by
establishing a relationship between the SSL session keys and the
tag protocol session keys (timing out and renewing together, for
example).
[0097] The present system allows data to be stored across multiple
smaller memory tags and presenting the tags as a single larger
memory tag. For example, a maintenance record update may be stored
in a tag applied to a machine (medical device, car, airplane) each
time it is maintained. The cache presents the record as a single,
coherent file even though it may actually be stored on many
individual tags. This is useful for simulating larger memories, and
also for closely associating non-contiguous data.
Security
[0098] A virtual tag can simulate security features not physically
present on the tag by: [0099] encrypting data before storing it on
the tag and decrypting the data after reading it from the tag
(managing the keys in the tag cache), allowing tags without on-tag
encryption and decryption capability to support this feature.
[0100] requiring that the user authenticate (for example, by
logging-in to a `tag web page` presented by the cache) before
accessing any or specific data areas. Even if the tag does not
support access control, the tag cache may simulate it by
controlling such access. [0101] simulating layered or nested
security in a tag (such as a patient wrist bracelet with their
medical record embedded, allowing the doctor to access all
information in the tag, the nurse less information, the insurance
company still less information, etc.) by combining encryption and
access control.
[0102] Multiple nested levels of security may be applied to tag
data, to allow fine-grained access control to the tag data based on
authentication. However, tags typically have limited computing
resources. To circumvent this limitation, there can be a single
encryption key for the tag data, held by the reader. The reader
then presents a `virtual tag` to the outside world, which simulates
a tag with granular access control. The reader uses its global
access (essentially acting in `superuser` mode) to perform the
actual tag transactions.
Tag Search
[0103] Tag cache 103 maintains the ID and data of the tags that
have been read within a certain period of time, and via
reader-to-reader cache updates, each reader 102 can mirror the tags
of any other reader. This process allows users to search for a
specific value (e.g., ID, state, contents), via traditional search
engine technology (if there are per-tag web pages), all tags 101
and readers 102 connected to the present system. The use of tag
cache 103 makes this process viable, as requests do not require
energizing the reader and tag for every request.
Sensor Cache
[0104] In one embodiment, sensor cache memory 103(S*) is used to
store sensor data read by tags and then sent to a reader 102.
Rather than having the reader constantly sample sensor data stored
in tag memory, sensor data values are updated, and trending (using
predictive modeling) is maintained, in sensor cache 103(S). The
present system implements a virtual RFID-based sensor by treating
sensor data from a remote sensor as if the sensor, with its own
entry in tag cache [i.e., sensor cache 103(S*)], were coupled
directly to the reader, functioning in the same manner as a sensor
[e.g., sensor 160(R)] that is attached (hardwired) to the
reader.
[0105] FIG. 5 is a flowchart showing an exemplary set of steps
performed in implementing a virtual sensor, which combines or
otherwise mathematically manipulates the outputs of one or more
actual sensors to simulate a new sensor type. As shown in FIG. 5,
at step 505, a tag [e.g., tag 101(1)] samples a sensor [e.g.,
sensor 160(1)], at a predetermined rate, to read data therefrom.
Alternatively, a tag may sample sensor data in response to command
from a reader. At step 510, the tag stores the sampled sensor data
in tag memory 152. In an exemplary embodiment, steps 505 and 510
are repeated at a predetermined sampling rate.
[0106] At step 515, a reader [e.g., reader 102(1)] reads the sensor
data from tag memory, and stores the data in sensor cache [e.g.,
103(S1)], at step 520. At step 525, as indicated by arrow 526,
reader 102(1) periodically updates sensor data in sensor cache
103(S1) using predictive modeling, as described below in detail
with respect to FIG. 6. Therefore, the reader maintains updated
sensor data without having to constantly read sensor data from a
tag, in effect providing a virtual sensor. Updated sensor data
stored in sensor cache 103(S1) may then be sent to a requesting
entity, such as tag processing system 104, without having the
reader perform an additional tag read operation to read sensor data
presently stored in a particular tag. Alternatively, the updated
sensor data may be sent periodically to a tag processing system,
without a specific request for the data.
[0107] At step 530, the reader delays sending the next command to
read sensor data. The delay period may be a predetermined amount of
time, or may be determined by the reader as a function of a
variable entity, such as time-of-day. After the delay period has
expired, the reader again reads sensor data stored in tag memory,
at step 515. The reader can also modify the delay time by tracking
the rate of change of the sensor output. Thus it can automatically
reduce the sample rate for sensors which have not historically
changed value very often.
[0108] FIG. 1C is an exemplary diagram of tag cache memory 103(S*),
including trending data 151 and a spatial map 152, in a tag reader
102(*) which is capable of reading the tags 101(*) in a grid or
array 165 of RFID tags, each of which has an attached sensor
160(*). FIG. 6 is a flowchart showing an exemplary set of steps
performed in updating sensor data in sensor cache 103(S*).
Operation of the present system is best understood by viewing FIGS.
1C and 6 in conjunction with one another. As shown in FIG. 6,
predictive modeling software included in code 109 of a reader
102(*) performs the functions set forth below.
[0109] At step 605, tag reader 102(*) reads sensor data from each
RFID tag 101(*) in tag sensor grid 165, and stores the results as
"trending data" 151 in sensor tag cache 103(S*). Trending data 151
comprises time-stamped sensor data read from more than one sampling
operation 505, which allows a present or future estimated value for
the sensor data to be determined from observed changes in data
values read from the sensors. At step 607, the data read from each
sensor is time-stamped, if the data does not already include
information indicating when the data was sampled. Trending data can
also be used to modify the sample rate of the sensor cache.
[0110] The grid of RFID tags may be rectangular, or the grid may
take a form of a possibly non-rectangular tag arrangement dictated
by the placement of tags in each room of a building, for example.
In the latter case, the tag reader may be mobile, and moved
throughout the building so that each of the tags in the grid 165
can be read. At step 610, a map 152 of sensor data for tag/sensor
locations 101(1,1) to 101(n,n) is generated. Then, at step 615, the
data in map 152 is extrapolated, using predictive modeling software
in code 109 of reader 102(*), to indicate a future state of sensor
data relative to the sensor grid 165.
[0111] A sensor grid 165, as shown in FIG. 1C, that is detecting
toxic gas in a cloud spreading over a field populated by the grid
of sensors 101(*,*) may be used as an example. Checking the
concentration of the gas at each sensor 160(*,*) and knowing the
location of each sensor enables a toxic gas cloud map 152 to be
generated. To accomplish this, tag reader 102(*) first reads sensor
data stored in each tag in grid 165, or in a significant number of
tags in the grid. Then, the data thus read is stored as trending
data 151 in tag cache 103(S*). Initially, a map 152 is created that
shows the existing gas concentration at each sensor 160(*,*). This
map can then be modified, using predictive modeling based on data
subsequently sampled from sensor grid 165.
[0112] Based on trending data 151 such as the change in
concentration of the gas over time, and/or known wind direction and
speed, sensor cache 103(*) stores information indicating what the
map is likely to look like at some point in the future, to aid
evacuation efforts, etc.
[0113] Certain changes may be made in the above methods and systems
without departing from the scope of that which is described herein.
It is to be noted that all matter contained in the above
description or shown in the accompanying drawings is to be
interpreted as illustrative and not in a limiting sense. For
example, the methods shown in FIGS. 2 through 6 may include steps
other than those shown therein, and the systems shown in FIGS. 1A,
1B, and 1C may include different components than those shown in the
drawings. The elements and steps shown in the present drawings may
be modified in accordance with the methods described herein, and
the steps shown therein may be sequenced in other configurations
without departing from the spirit of the system thus described. The
following claims are intended to cover all generic and specific
features described herein, as well as all statements of the scope
of the present method, system and structure, which, as a matter of
language, might be said to fall there between.
* * * * *