Locating, provisioning and identifying devices in a network

The present invention encompasses a variety of methods for accomplishing these goals. One such method will now be described with reference to Fig. 7. Method 700 begins with a determination of whether to send information to a network device regarding the current personality of the RFID device (step 701). Here, the RFID device will send the information to a DHCP server if a predetermined period of time has elapsed. In this example, the predetermined period of time is one hour, but it could be any convenient period of time.

If it is time for another DHCPREQUEST or DHCPINFORM message to be sent to the DHCP server, the RFID device forms the request (step 705). If not, the current personality is maintained (step 702). In this example, the information will be sent in a DHCP request (RFC 2131) combined with DHCP Option 125, Option 61 or Option 43 set to the RFID device’s EPC (or equivalent) and Option 77 set to the RFID device’s current personality. Using DHCPREQUEST, DHCPINFORM and DHCP Options, the RFID device is able to pass current identification, provisioning and personality information.

In this example, a cached secret (e.g., hashed with the contents of the DHCP message including the client EPC) will be included with the DHCP request in order to secure the response. The secret could be provided, for example, during an earlier

WO 2005/114604

PCT/US2005/016958 provisioning stage, e.g., the initial provisioning stage of the RFID device. The secret could be used in the DHCPINFORM validation process and for other processes.

The request is sent in step 710. Preferably, a relay agent updates the request with location information, as described above (step 715).

Tn step 720, the server compares the information in the request with stored information (e.g., in a lookup table or a database) to determine whether an update or a complete reconfiguration of the RFID device is required. If not, the process returns to step 701. If so, the server provides the RFID device with the necessary update and/or reconfiguration information (step 725).

The RFID device triggers the update and/or reconfiguration determination in the foregoing example. However, in other implementations, another device (e.g., the DHCP server) and/or a person initiates this determination. For example, the DHCP server could initiate a periodic process of comparing a desired RFID device personality with the last known RFID device personality. Alternatively, an IT worker could send information (e.g., to the DHCP server, to the RFID device or to another device) indicating a desired change in personality.

According to some implementations of the invention, a DHCP server causes an update or a complete reconfiguration using a DHCPFORCERENEW command as defined by RFC 3203, which is hereby incorporated by reference in its entirety. The CPU of the RFID device registers the DHCPFORCERENEW command and starts a new provisioning cycle, for example as described above with reference to Fig. 6.

Tn order to secure the command, in this example a cached secret is hashed within the command. For example, the secret can be included with the EPC code of the RFID device.

One method for creating an authentication key is as follows:

MD-5 (EPC, Challenge, Secret)

By adding in the variable of a random Challenge, no replay attacks of the hash code could be used. Because the EPC is included, the authentication can be further validated to come from a specific device.

The foregoing methods allow for unique determination and provisioning of RFID devices by time of day, not simply by device “type,” “class” or “location.” Moreover, the foregoing methods allow for ongoing verification/auditing of what the end device roles are. In addition, these methods allow operation managers to have

CANRPonbhDCCATR WiH Ι7Ά_ l DOC-29rtK.Q(H0

2005246794 29 Jun 2010 enterprise resource planning systems control end devices to allow for increased functionality. Fig. 8 is a flow chart that illustrates an exemplary business application of some embodiments. Those of skill in the art will appreciate that the example described below with reference to Fig. 8 is but one of many applications of described embodiments.

In step 805, an RFID device has already been provisioned according to one of the previously-described methods. The condition of the RFID device is comparable to that of a device at step 640 in method 600, shown in Fig. 6 and described above. In this example, the RFID device is an RFID reader that is positioned near an exit door of a retail store. Therefore, in the previous steps, the device has been provisioned with a personality that is appropriate for 10 its role.

In step 810, a shopper exits the door with a number of selected products. In step 815, the RFID reader reads the RFID tags of each product and extracts the EPC codes and related product information (e.g., the price of each product).

The RFID reader also reads an RFID tag that identifies the shopper and the shopper's preferred account(s) that should be debited in order to purchase the products. For example, the shopper may have an RFID tag embedded in a card, a key chain, or any other convenient place in which this information is encoded. The accounts may be various types of accounts maintained by one or more financial institutions. For example, the accounts may be one or more of a checking account, savings account, a line of credit, a credit card account, etc.

Biometric data (e.g., voice, fingerprint, retinal scan, etc.) from the shopper may also be obtained and compared with stored biometric data in order to verify the shopper's identity.

In step 820, the RFID reader transmits the product information, including the EPC codes, on the RFID network. In this example, the information is first sent to a financial institution indicated by the shopper's RFID tag.

In step 825, the financial institution that maintains the shopper's selected account determines whether there are sufficient funds (or whether there is sufficient credit) for the shopper to purchase the selected products. If so, the shopper's account is debited and the transaction is consummated (step 830).

In this example, the shopper has the option of designating one or more alternative accounts. Accordingly, if the first account has insufficient funds or credit, it is determined (e.g., by a server on the RFID network) whether there the shopper has indicated any alternative accounts for making purchases (step 835). If so, the next

WO 2005/114604

PCT/US2005/016958 account is evaluated in step 825. If it is determined in step 835 that there are no additional accounts designated by the shopper, in this example some form of human intervention takes place. For example, a cashier of the retail store could assist the shopper in making the purchases in a conventional manner.

If some or all of the products are purchased, information regarding the purchased products (including the EPC codes) are transmitted on the RFID network. For example, this information is preferably forwarded to one or more devices on the RFID network that are configured to update one or more databases maintained by the retail store or the manufacturers/producers, distributors, wholesalers, etc., of the purchased products (step 840). In some implementations, information regarding the shopper is also transmitted on the RFID network (e.g., if the shopper has authorized such information to be released). This product information (and optionally shopper information) may be used for a variety of purposes, e.g., in the formation of various types of business plans (e.g., inventory re-stocking, marketing, sales, distribution and manufacturing/production plans).

Some implementations of the invention provide alternative methods of provisioning devices, including but not limited to RFID devices. Some such methods will now be discussed with reference to Figs. 9 et seq.

In Fig. 9A, RFID reader 905 is in communication with switch 910. This communication may be via a wired link, as illustrated by optional link 915 between RFID reader 905 and port 917. Alternatively, the communication may be via a wireless link, e.g., via wireless link 920 between antenna 925 of RFID reader 905 and antenna 927 of access point 930. RFID device 907 is connected via line 918 to port 919.

Switch 910, as well as switches 912, 914 and 916, can communicate with DHCP server 935 via network 940. Network 940 may be any convenient type of network, but in this illustration at least part of network 940 includes a portion of the Internet.

In some implementations of the invention, DHCP server 935 performs tasks that, in other implementations, are performed by device 945. Device 945 may be one of various types of computing devices, including a host device, a server, etc. In some implementations, device 945 is a Lightweight Directory Access Protocol (“LDAP”) server. LDAP is a set of protocols for accessing information directories and is based on the standards contained within the X.500 standard, but is significantly simpler.

WO 2005/114604

PCT/US2005/016958

Unlike X.500, LDAP supports TCP/IP. In some implementations, DHCP server 935 and device 945 are in the same chassis 950. In other implementations, DHCP server

935 and device 945 are in direct communication (as shown by link 955) or communicate via network 940.

Accordingly, RFID reader 905 can read RFID tags (including but not limited to location tag 960) and transmit them to devices in communication with network 940. Preferably, location tag 960 is positioned in a relatively fixed location, e.g., is mounted on a wall, a door frame, or another structural element of a building. In alternative embodiments, location tag 960 is portable.

Location tag 960 includes what will sometimes be referred to herein as “location data,” “location information” or the like. The location information may include any convenient type of absolute or relative coordinate, positioning, cartographic or similar information and/or information from which such information may be derived. For example, in some implementations location tag 960 includes latitude/longitude, X,Y coordinate information and/or elevation information. In other implementations, location tag 960 includes “civil address” information, which may include street address, building, floor, room/area and/or other such information.

Alternatively, the location information may be in the form of a code, such as a numerical or alphanumeric code, from which absolute location information (such as coordinate, latitude/longitude, civil address, etc.) may be derived. For example, a data structure accessible by DHCP server and/or device 945 may include codes and corresponding absolute location information. Accordingly, DHCP server and/or device 945 may access the data structure and determine absolute location information that corresponds to a code encoded in location tag 960. The data structure may be a look-up table, a database, etc. The data structure may be stored in a local memory or in one or more of networked storage devices 947.

Middleware servers 952 and 954 provide data collection and filtering services, such as taking out redundancies, searching for particular RFID tag reads, etc. Accordingly, only a portion of the data received by the middleware servers is routinely made available to higher-level applications. Middleware servers are sometimes referred to herein as “ALE” (application level event) devices or the like.

IT personnel monitoring the system, troubleshooting, etc., may use a device such as management station 957, which is a desktop computer in this example. A management station may be configured to receive, display and analyze raw and/or

C:\NRPortbl\DCC\TRNWi3 l?V3_ I DOC-29/06/2010

2005246794 29 Jun 2010 filtered reads and to perform follow-up tasks such as interrogating devices in the network. Location tag 960 may be encoded in any convenient manner, including by proprietary methods and/or methods that conform, at least in part, to existing standards. In general, it is preferable to deploy location tags that are encoded according to existing standards in order to simplify programming of related devices, to avoid non-uniqueness problems and generally to lower the costs of implementation. Location tag 960 may be formed, e.g., as an RFID tag or as any type of bar code. One example of a format for at least a portion of location tag 960 is shown in Fig. 9B. Here, location tag 960 is in the general format of a Global Location Number (GLN). Some exemplary GLN formats are defined, for example, in the Global Location Number (GLN) Implementation Guide, (Uniform Code Council, 2002), which is hereby incorporated by reference for all purposes. Accordingly, location tag 960 includes a 13-digit GLN. Field 965 is a company prefix field, which indicates the prefix assigned to an entity by the Uniform Code Council or an EAN member organization. Field 972 is a check digit field that contains a one-digit number used to ensure data integrity.

The length of location reference field 970, which is a nine-digit field in this example, varies according to the length of the assigned company prefix field 965. Location reference field 970 may be assigned to identify uniquely a selected location. Accordingly, location reference field 970 may be customized according to an organization's desires and/or requirements. In the example shown in Fig. 9C, location reference field 970 has been defined by an entity to according to a 3-digit building field 975, a 2-digit floor field 980, a 1-digit function field 985 and a 3-digit area field 990. In this example, the location is a particular door in a receiving area of a warehouse.

Fig. 10 is a flow chart that outlines method 1000 according to some embodiments.

In step 1001, a device initializes. According to method 1000, the device obtains location data before the device is configured with an IP address and other network configuration information. (Step 1005.)

In some implementations, the location data are obtained in step 1005 by reading a location tag that is positioned nearby. Accordingly, location tags have previously been positioned in locations where devices were expected to be used. The identifiers and locations of the location tags have preferably been recorded

WO 2005/114604

PCT/US2005/016958 in a central management system. In some such implementations, when a device (e.g., a wireless RFID reader) is first turned on, the device prompts the user to swipe the reader past a location tag. Swiping may not be necessary if, for example, the location tag is an RFID tag and the reader is capable of reading tags at a sufficient distance.

In alternative implementations, the location data are obtained in step 1005 according to other methods, e.g., from an associated device that has Global Positioning System (“GPS”) capability. In some such implementations, the device itself includes GPS functionality.

In step 1008, the location data are included in an option field of the DHCPDISCOVER request, for example in option 43 (RFC 2132) or option 125 (RFC 3925). These RFCs are hereby incorporated by reference for all purposes. The DHCPDISCOVER request is then sent to a DHCP server. (Step 1010.)

In step 1015, it is determined whether the device’s location can be determined from the location data in the DHCPDISCOVER request. The determining step includes extracting the location data from an option field of the DHCPDISCOVER request. As noted above, in some implementations the location data may be a code that can be used to cross-reference objective location data that could be meaningful for the purpose of device provisioning. In other implementations (e.g., as described above with reference to Figs. 9B and 9C), such objective location data are encoded in the request itself.

The process of determining and/or evaluating the location data may be performed by the DHCP server itself (e.g., by DHCP server 935 of Fig. 9A) or may be performed, at least in part, by another device (e.g., by device 945 of Fig. 9A). Information relevant to steps 1015,1018 and 1020 may be stored by one of these devices, by a local storage device or by networked storage devices 947. (See Fig. 9A.) If objective location data can be determined in step 1015, the process continues to step 1018. If not, the process ends.

In this example, objective location data were encoded as shown in Fig. 9C and it is determined in step 1015 that the device is located near the indicated receiving door of a particular floor of a warehouse. In step 1018, it is determined whether there are stored configuration data that correspond to the objective location data determined in step 1015. Either step 1015 or step 1018 (in this example, step 1018) also involves determining a device type, e.g., according to methods discussed elsewhere herein. Here, it is determined in step 1018 that the device is a particular type of RFID reader.

WO 2005/114604

PCT/US2005/016958

Moreover, it is determined in step 1018 that configuration data appropriate for that type of RFID device and for the location determined in step 1015 have previously been stored. Tn this example, it is determined in step 1018 that location data for the device, such as a logical name, are also available.

Accordingly, in step 1020 an appropriate IP address, other network configuration information, location data and an operating system image for the RFID reader are obtained. Such data will sometimes be collectively referred to herein as “configuration data” or the like. In this example, an appropriate device personality has also been stored. This personality is determined in step 1018 and is provided in step 1025 through a DHCP message exchange, using one or more DHCP Options. For example, coordinate based location information can be returned in the DHCP Option for Coordinate-based Location Configuration Information (RFC 3825), which is hereby incorporated by reference. Civic address location information can be returned in the DHCP Option for Civic Addresses Configuration Information (draftietf-geopriv-dhcp-civil-04), which is also incorporated by reference. Other location tags can be returned as a Vendor-Identifying Vendor Option (RFC 3925), which has already been incorporated by reference herein. A logical name could be returned via DHCP Option 12.

DHCP and DNS can accomplish provisioning based on location. The DHCP server could return a random address from a pool of addresses and also could return a specific host name to the RFID reader. Middleware typically has a pre-configured specific IP address or specific host name, corresponding to a particular RFID reader. It will be apparent to those of skill in the art that hard-coding a specific IP address in the middleware will not work if the DHCP server is handing out “random” IP addresses from a pool.

Therefore, in some implementations of the invention, the specific host name is hard-coded within the middleware server. When the DHCP server hands back a random IP address corresponding to a particular RFID reader, it can update a dynamic DNS server. The DNS server binds the random IP address to the specific host name. In this case, because the DHCP server assigned the host name to the device based upon the location of the device (e.g., from the DHCP Option 82 information) one can ensure that the IP address is bound to the correct host name.

The device is configured accordingly, e.g., as described elsewhere herein.

(Step 1030.) In some preferred implementations, a middleware server will instruct

WO 2005/114604

PCT/US2005/016958 the reader to include location information within each tag read, in whatever form the middleware server designates, e.g., as a location EPC, as geographic coordinates or as a logical name of the reader (i.e. device name or host name). For example, the middleware server could send XML commands instructing the reader to set its name to a logical name (e.g., “dock door 100”). In some such implementations, the logical name will include additional civic address information (e.g., “warehouse A”) and/or cartographic information, such as (x,y,z) coordinates, latitude/longitude, etc.

Location data received in the provisioning process are preferably stored locally, e.g., in a memory of each provisioned RFID reader. When the middleware initiates a session to the reader, it queries the DNS server using the hard-coded host name. The DNS server responds with the IP address bound to that host name and the middleware is able to connect to the RFID reader.

After RFID readers are provisioned and configured according to methods of the present invention, the RFID readers read RFID tags (step 1035) and transmit RFID data from the RFID tags (sometimes referred to herein as “raw reads” or the like) to middleware servers, such as middleware servers 952 and 954 of Fig. 9 A. In some preferred implementations of the invention, an RFID reader will also encode and transmit location data (such as a logical name) obtained during the provisioning process, along with the raw reads. (Step 1040.) An example of such a read is described below with reference to Fig. 13.

In some such implementations, these location data are transmitted with every raw read. As noted elsewhere herein, a logical name has meaning without the need to cross reference, e.g., a device ID number. Accordingly, a logical name would have meaning to IT personnel monitoring the system, troubleshooting, or otherwise trying to determine the significance of the reads. Such tasks may be performed, for example, via management station 957.

Some implementations of the invention use alternative methods of determining a device’s location. For example, some methods that are suitable for wireless devices use location determination techniques that are outlined in one or more of the IEEE 802.11 specifications, (e.g., 802.11b), which are hereby incorporated by reference for all purposes.

Some such implementations will now be described with reference to the network diagram of Fig. 11 and the flow chart of Fig. 12. Fig. 11 depicts wireless device 1105, which is a wireless RFID reader in this example. In alternative

WO 2005/114604

PCT/US2005/016958 implementations, wireless device 1105 maybe another type of wireless device, such as a portable digital assistant or a laptop computer having a wireless interface. The signals from wireless device 1105 can be detected by wireless access points (“WAPs”) 1101,1102 and 1103, which are in communication with switches 1111 and

1112.

According to method 1200 of Fig. 12, wireless device 1105 initializes and forms an association with access point 1101 (step 1205). All 802.11 devices associate with only a single access point at any one time. Therefore, wireless device 1105 can only associate with a single access point. Access points 1102 and 1103 can “see” wireless device 1105 because a wireless network is a shared medium. However, wireless device 1105 directs its traffic towards access point 1101, with which it has an association.

According to the 802.1 lb specification, a wireless device will periodically send out a special wireless frame (packet) which is specifically understood to go to all access points. The special frame, which is typically implementation dependent, usually contains an identifier for the particular wireless device. Such special frames will be referred to herein as “location frames” or the like. Accordingly, in step 1210 wireless device 1105 sends, out a location frame that is received by access points 1101,1102 and 1103. The location frame includes an identifier, which could be the MAC address of wireless device 1105, some other identification number, an EPC value coded into the RFID device, etc.

When an access point receives a location frame, the access point forwards the location frame to a management server that aggregates the information from various access points. Each access point may insert a timestamp of when it received the frame and/or the power level (Received Signal Strength Indicator or “RSSI”) of the received frame before forwarding it to the management server. These data will sometimes be referred to herein as “IEEE 802.1 lb location data” or the like.

Such IEEE 802.1 lb location data may include what could be termed “triangulation data,” in that the data may be used to locate the wireless device by triangulation techniques. However, some types of IEEE 802.1 lb location data are not, strictly speaking, triangulation data. Instead, these data reference other location information, e.g., system map data.

Accordingly, in step 1215, access points 1101,1102 and 1103 insert IEEE

802.1 lb location data into the location frames received from wireless device 1105

WO 2005/114604

PCT/US2005/016958 and forward the location frames to management server 1120. Therefore, management server 1120 will receive multiple frames containing the device identifier for wireless device 1105 from different access points. Switch 1113 is shown in Fig. 11 to be hard wired to management server 1120, DHCP server 1125, LDAP server 1130 and switch 1111. Switch 1113 is depicted as being in communication with switch 1112 via network 1160, which is a local area network in this example. However, it will be appreciated by those of skill in the art that this is merely a simple example of how these and other devices of network 1100 may communicate. For example, switch 1113 may communicate with one or more of management server 1120, DHCP server 1125, LDAP server 1130, switch 1112 and switch 1111 via a network such as an intranet and/or the Internet.

Tn step 1225, management server 1120 attempts to determine the location of wireless device 1105 using the IEEE 802.1 lb location data in the location frames. The access points have preferably been mapped into the management server, so their location is known. Based upon the IEEE 802.1 lb location data (e.g., the RSSI or timestamp) in the special frames, the management server can use algorithms to determine the location of wireless device 1105.

Management server 1120 may show the location of wireless device 1105 on a map that was pre-configured in a management station at the same time the access points were added to the management station. This location could be indicated in terms of a geographical coordinate. Alternatively, or additionally, management server may be configured to designate portions of a map to correspond to a predetermined location name such as dock door 101 or back stockroom.

If management server 1120 cannot determine the location of wireless device 1105, method 1200 ends. The location may nonetheless be determined by alternative methods described herein. However, if management server 1120 can determine the location of wireless device 1105, management server 1120 will store the location and may update a memory of another device, e.g., of LDAP server 1130. (Optional step 1230.)

In step 1235, wireless device 1105 sends a DHCPDISCOVER request, with a device identifier, to DHCP server 1125. Unlike the special location frame, the DHCPDISCOVER request only goes to the access point with which wireless device 1105 has an association (access point 1101). Switch 1111, to which access point 1101 is connected, may optionally add location data as described elsewhere herein.

WO 2005/114604

PCT/US2005/016958

For example, switch 1111 may include location data in Option 82. Switch 1111 forwards the DHCPDISCOVER request to DHCP server 1125 via switch 1113. In some implementations, switch 1113 functions as a relay agent and inserts a gateway address in the DHCPDISCOVER request if DHCP server is on a separate IP subnet.

In step 1250, DHCP server 1125 queries management server 1120 and/or LDAP server 1130 to determine whether there is a location corresponding to information (e.g., ID information) in the DHCPDISCOVER request. If not, method 1200 ends.

Tn one such example, DHCP server 1125 queries management server 1120 for the location of the device upon receiving the DHCPDISCOVER request. DHCP server 1125 could use the MAC address, EPC value or another identifier coded into the DHCPDISCOVER request in order to reference wireless device 1105 to management server 1120. Management server 1120 could return the location of the RFID device to the DHCP server via the network. Depending on the implementation, management server 1120 could return a geographical coordinate or a predetermined location name such as dock door 101.

DHCP server 1125 could query LDAP server 1130 for such information in a similar fashion. If management server 1120 is updating LDAP server 1130, DHCP server 1125 could obtain these and other data from LDAP server 1130.

If a device location is determined, DHCP server 1125 determines whether there are configuration data, personality data, etc. appropriate for the location and for the device type indicated in the DHCPDISCOVER request as described elsewhere herein. If there are not, method 1200 ends. If such data are found, DHCP server 1125 obtains these data (step 1255) and provides them to wireless device 1105. (Step 1260.) In this example, it is determined in step 1250 that location data for the device, such as a logical name, are also available. Accordingly, these data are also obtained in step 1255 and provided to wireless device 1105 in step 1260. Wireless device 1105 is provisioned accordingly in step 1265.

After an RFID reader is provisioned and configured, the RFID reader is ready for normal operation. The RFID reader will read RFID tags (step 1270) and transmit raw reads from the RFID tags to middleware servers, such as middleware servers 952 and 954 of Fig. 9 A or middleware server 1170 of Fig. 11. In this example, the RFID reader will also encode and transmit location data (such as a logical name) obtained during the provisioning process, along with the raw reads. (Step 1275.) The logical

C \NRPonbMX?CVrRKA3O31793 1 DOC-2*M*»/2H 10

2005246794 29 Jun 2010 name would have meaning to IT personnel monitoring the system, troubleshooting, etc. Fig. 13 illustrates one exemplary format of an RFID read that includes a logical device name and/or device location data. In this example, the RFID reader is communicating with a middleware server over an Ethernet and has encoded RFID tag read

1300 in an XML document. Accordingly, the outermost layer of encapsulation is Ethernet layer 1305. Within Ethernet layer 1305 are IP datagram 1310 and TCP layer 1315. Accordingly, XML document 1325 is embedded in HTTP message 1320, which is encapsulated in a TCP/IP packet within an Ethernet frame.

In this example, XML document 1325 includes both a logical name (dockDoorlOO) and latitude/longitude/altitude data, as follows:

<?xml version-'1.0 encoding=UTF-8>

<rfidReader>

<readerName name-'dockDoor 100>

<readerLocation>

<locationCoordinates>

<lattitude>053C 1F751 </lattitude>

<longitude>F50BA5B97</longitude> <altitude>00006700</altitude>

</locationCoordinates>

</readerLocation>

<readPoint id= 1 >

<epc >000000000000000000000001 </epc>

</readPoint>

</readerName>

</rfidReader>

Within the XML document, there is a single EPC tag read value (<epc >000000000000000000000001 </epc>).

Fig. 14 is a flow chart that outlines a simplified method 1400 for using the location data and RFID tag reads provided by some embodiments. Some steps of method 1400 may be performed, for example, by (and/or via) a management station such as management station 957 of Fig 9A or management station 1150 of Fig. 11.

In step 1405, location data and RFID tag reads are received. In some systems of the

ClNRPonbhDCCTRt>A.UH|793_l DOC-2W6/2010

2005246794 29 Jun 2010 prior art, a raw read might identify the originating RFID reader by using an identification number, such as a MAC address of the reader. The raw reads from a number of RFID readers are displayed, e.g., on a display monitor of a management station.

Instead of identifying a raw read as being from an RFID reader identified by a number, according to some embodiments the read is associated with a location and/or a function via a logical name such as dock door A, Building 22, 3^rd floor, conference room B, etc. Accordingly, it may be easier for IT personnel to determine when a problem is indicated (step 1415) and/or to more quickly address the problem (step 1420) and resolve it (step 1425) when such a problem is indicated.

In one example, an IT person is managing an RFID network for a factory and associated warehouses. The IT person is using a management station for this purpose, which has a screen that displays information about the various components of the network. For example, the screen may normally display many rows of entries that indicate at least part of a raw read and corresponding location data. In this example, the management station includes software that allows the IT person to display RFID reads according to various criteria, at least some of which correspond to location data. For example, the IT person is able to display all reads within a certain time frame that came from a particular location, e.g., from a particular dock door of a particular building. Accordingly, the IT person will be able to detect problems more easily. (Step 1415.)

The management station may also include software that provides for automatic notification when a predetermined event happens (or fails to happen). For example, a box may pop up on the display screen that indicates a problem, e.g., I have not heard from [logical name of device] in 2 hours or [logical name of device] just sent a message indicating antenna failure. (Step 1415.)

The IT person may address such a problem (step 1420) more readily, because the problem indicated will be associated with a particular location name/logical name. For example, the problem may be addressed by interrogating an RFID device and/or the associated middleware server, by rebooting an RFID device, by notifying a person who works in or near the location indicated to replace a defective RFID device, etc. After the problem is resolved (step 1425), the management station will continue to receive and monitor RFID reads.

Fig. 15 illustrates an example of a network device that may be configured to implement some of the described methods. Network device 1560 includes a master central

C iNRPonbI\DCC\TRN\3lB|793_l DOC*29W2(>10

2005246794 29 Jun 2010 processing unit (CPU) 1562, interfaces 1568, and a bus 1567 (e.g., a PCI bus). Generally, interfaces 1568 include ports 1569 appropriate for communication with the appropriate media. In some embodiments, one or more of interfaces 1568 includes at least one independent processor 1574 and, in some instances, volatile RAM. Independent processors 5 1574 may be, for example ASICs or any other appropriate processors. According to some such embodiments, these independent processors 1574 perform at least some of the functions of the logic described herein. In some embodiments, one or more of interfaces 1568 control such communications-intensive tasks as media control and management. By providing separate processors for the communications-intensive tasks, interfaces 1568 allow the master microprocessor 1562 efficiently to perform other functions such as routing computations, network diagnostics, security functions, etc.

The interfaces 1568 are typically provided as interface cards (sometimes referred to as line cards). Generally, interfaces 1568 control the sending and receiving of data packets over the network and sometimes support other peripherals used with the network device 1560. Among the interfaces that may be provided are Fibre Channel (FC) interfaces, Ethernet interfaces, frame relay interfaces, cable interfaces, DSL interfaces, token ring interfaces, and the like. In addition, various very high-speed interfaces may be provided, such as fast Ethernet interfaces, Gigabit Ethernet interfaces, ATM interfaces, HSSI interfaces, POS interfaces, FDD1 interfaces, ASI interfaces, DHEI interfaces and the 20 like.

When acting under the control of appropriate software or firmware, in some implementations CPU 1562 may be responsible for implementing specific functions associated with the functions of a desired network device. According to some embodiments, CPU 1562 accomplishes all these functions under the control of software including an operating system (e.g. Linux, VxWorks, etc.), and any appropriate applications software.

CPU 1562 may include one or more processors 1563 such as a processor from the Motorola family of microprocessors or the MIPS family of microprocessors. In an alternative embodiment, processor 1563 is specially designed hardware for controlling the 30 operations of network device 1560. In a specific embodiment, a memory 1561 (such as non-volatile RAM and/or ROM) also forms part of CPU 1562. However, there are many different ways in which memory could be coupled to the system. Memory block 1561 may be used for a variety of purposes such as, for example, caching and/or storing data,

C \NRPortbl\DCCTRN\K)l 17¥1_ I DOC-29rtXi/201&lt;)

2005246794 29 Jun 2010 programming instructions, etc.

Regardless of a network device's configuration, it may employ one or more memories or memory modules (such as, for example, memory block 1565) configured to store data, program instructions for the general-purpose network operations and/or other information relating to the functionality of the techniques described herein. The program instructions may control the operation of an operating system and/or one or more applications, for example.

Because such information and program instructions may be employed to implement the systems/methods described herein, some embodiments relates to machine-readable media that include program instructions, state information, etc. for performing various operations described herein. Examples of machine-readable media include, but are not limited to, magnetic media such as hard disks, floppy disks, and magnetic tape; optical media such as CD-ROM disks; magneto-optical media; and hardware devices that are specially configured to store and perform program instructions, such as read-only memory devices (ROM) and random access memory (RAM). Implementations may also be embodied in a carrier wave traveling over an appropriate medium such as airwaves, optical lines, electric lines, etc. Examples of program instructions include both machine code, such as produced by a compiler, and files containing higher level code that may be executed by the computer using an interpreter.

Although the system shown in Fig. 15 illustrates one specific network device, it is by no means the only network device architecture on which embodiments can be implemented. For example, an architecture having a single processor that handles communications as well as routing computations, etc. is often used. Further, other types of interfaces and media could also be used with the network device. The communication path between interfaces/line cards may be bus based (as shown in Fig. 15) or switch fabric based (such as a cross-bar).

Other Embodiments

Although illustrative embodiments and applications of this invention are shown and described herein, many variations and modifications are possible which remain within the concept, scope, and spirit of the invention.

Accordingly, the present embodiments are to be considered as illustrative and not restrictive, and the invention is not to be limited to the details given herein, but may be modified within the spirit and scope of the invention.

C \NRPortbl\DCaTRNL3l>M7‘n_l .DOC-2W06/2010

2005246794 29 Jun 2010

Throughout this specification and the claims which follow, unless the context requires otherwise, the word comprise, and variations such as comprises and comprising, will be understood to imply the inclusion of a stated integer or step or group of integers or steps but not the exclusion of any other integer or step or group of integers or 5 steps.

The reference in this specification to any prior publication (or information derived from it), or to any matter which is known, is not, and should not be taken as an acknowledgment or admission or any form of suggestion that that prior publication (or information derived from it) or known matter forms part of the common general knowledge.

WO 2005/114604

PCT/US2005/016958