Source: http://www.google.com/patents/US7648070?dq=7,321,221
Timestamp: 2016-02-13 13:59:15
Document Index: 25779003

Matched Legal Cases: ['Application No. 60', 'Application No. 2005246794', 'Application No. 200580015167', 'Application No. 200580015168', 'Application No. 200580015169', 'Application No. 2', 'Application No. 2', 'Application No. 2', 'Application No. 200580015168', 'Application No. 200580015167', 'Application No. 200580015169']

Patent US7648070 - Locating, provisioning and identifying devices in a network - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inPatentsMethods and devices are provided for locating, identifying and provisioning devices in a network. According to some implementations of the invention, a combination of EPC code information and existing networking standards form the basis of identifying and provisioning methods. For example, first location...http://www.google.com/patents/US7648070?utm_source=gb-gplus-sharePatent US7648070 - Locating, provisioning and identifying devices in a networkAdvanced Patent SearchPublication numberUS7648070 B2Publication typeGrantApplication numberUS 11/129,709Publication dateJan 19, 2010Filing dateMay 12, 2005Priority dateMay 13, 2004Fee statusPaidAlso published asCN1954327A, CN1954328A, CN1954329A, CN100531082C, CN100531083C, CN100561499C, CN101263506A, CN101263506B, US7422152, US8060623, US8601143, US20050252971, US20050253722, US20050264420, US20080197980, US20120036243Publication number11129709, 129709, US 7648070 B2, US 7648070B2, US-B2-7648070, US7648070 B2, US7648070B2InventorsRalph Droms, Gary Dennis Vogel, Jr., Roland SavilleOriginal AssigneeCisco Technology, Inc.Export CitationBiBTeX, EndNote, RefManPatent Citations (96), Non-Patent Citations (124), Referenced by (39), Classifications (29), Legal Events (3) External Links: USPTO, USPTO Assignment, EspacenetLocating, provisioning and identifying devices in a network
US 7648070 B2Abstract
Methods and devices are provided for locating, identifying and provisioning devices in a network. According to some implementations of the invention, a combination of EPC code information and existing networking standards form the basis of identifying and provisioning methods. For example, first location information included in a DHCPDISCOVER request can be used to determine appropriate configurations for networked devices. In some such implementations, the first location information is read from an RFID tag near the networked device and is inserted in the DHCPDISCOVER request. The first location information may include any type of absolute or relative coordinate, positioning, cartographic or similar information and/or information from which such information may be derived. Second location information, which may be a logical name, is provided to the device. If the device is an RFID reader, the second location information may be included with reads from RFID tags that are transmitted from the RFID reader.
1. A method of provisioning a device, the method comprising:
initializing a radio frequency identification (“RFID”) device;
reading RFID tag data from an RFID tag;
inserting the RFID tag data in an option field of a DHCPDISCOVER request;
sending the DHCPDISCOVER request to a Dynamic Host Configuration Protocol (“DHCP”)server;
ascertaining, based at least in part on the RFID tag data, a location and a logical name of the RFID device;
determining, based in part on the location of the RFID device, an appropriate configuration for the RFID device; and
provisioning the RFID device according to the appropriate configuration, wherein the provisioning step comprises provisioning the RFID device with a logical name.
2. The method of claim 1, wherein the RFID device is a wireless RFID device.
3. The method of claim 2, wherein at least one step is performed by the DHCP server.
4. The method of claim 1, wherein the ascertaining step comprises accessing a data structure that includes RFID tag data and corresponding location data and logical names.
5. The method of claim 1, wherein at least part of the ascertaining step is performed by the DHCP server.
6. A method of provisioning a wireless device, the method comprising:
receiving IEEE 802.11b location data from a plurality of wireless access points;
ascertaining, based at least in part on the IEEE 802.11b location data, a location and a logical name of a radio frequency identification wireless device;
determining an appropriate configuration for the wireless device according to the location; and
provisioning the wireless device, wherein the configuring step comprises supplying the wireless device with the appropriate configuration and with a logical name.
7. The method of claim 6, wherein the IEEE 802.11b location data comprise one of time data and signal strength data.
8. A method for deploying a uniquely-provisioned radio frequency identification (“RFID”) device in a network, the method comprising:
reading first location information from a first RFID tag;
forming a DHCPDISCOVER request that includes an electronic product code (“EPC”) of an RFID reader and the first location information;
receiving provisioning information from the DHCP server that enables a desired functionality according to an identity and a location of the RFID reader, the provisioning information including second location information; and
provisioning the RFID reader according to the provisioning information, thereby enabling the RFID reader to read nearby RFID tags and to transmit RFID tag information and second location information to an RFID network.
9. The method of claim 8, wherein the first location information comprises one of coordinate information and civil address information.
10. The method of claim 8, wherein the second location information comprises a logical name.
a plurality of radio frequency identification (“RFID”) devices;
a plurality of switches connecting the RFID devices to the network; and
a Dynamic Host Configuration Protocol (“DHCP”) server, wherein at least some of the RFID devices comprise:
one or more RF radios configured for reading first location information from a first RFID tag;
a central processing unit configured to do the following:
form a DHCPDISCOVER request that includes an electronic product code (“EPC”) of an RFID reader and the first location information;
send the DHCPDISCOVER request to the DHCP server via the network interface;
receive, via the network interface, provisioning information from the DHCP server that enables a desired functionality according to an identity and a location of the RFID reader, the provisioning information including second location information; and provision the RFID reader according to the provisioning information, thereby enabling the RFID reader to read nearby RFID tags and to transmit RFID tag information and second location information to an RFID network; and
wherein the DHCP server comprises:
an interface for receiving the DHCPDISCOVER request; and
a processor configured to do the following:
automatically identify an RFID device according to a media access control (“MAC”) address and an EPC included in the DHCPDISCOVER request;
locate the RFID device;
determine the second location information according to the first location information included in the DHCPDISCOVER request; and
provide, via the interface, the RFID device with a desired functionality and the second location information.
12. A method of provisioning a device, the method comprising:
initializing an RFID device;
obtaining first location data;
inserting the first location data in an option field of a DHCPDISCOVER request; and
determining provisioning information, including a logical name, based at least in part on the first location data;
providing the provisioning information to the device;
configuring the device according to the provisioning information;
reading RFID tag data from RFID tags; and
transmitting the RFID tag data to a middleware server along with the logical name.
13. The method of claim 12, wherein the RFID device includes global positioning system (“GPS”) capability and wherein the first location data comprise GPS data.
14. A network for provisioning a device, the network comprising:
means for initializing a radio frequency identification (“RFID”) device;
means for reading RFID tag data from an RFID tag;
means for inserting the RFID tag data in an option field of a DHCPDISCOVER request;
means for sending the DHCPDISCOVER request to a Dynamic Host Configuration Protocol (“DHCP”)server;
means for ascertaining, based at least in part on the RFID tag data, a location and a logical name of the RFID device;
means for determining, based in part on the location of the RFID device, an appropriate configuration for the RFID device; and
means for providing the RFID device with provisioning information comprising a logical name and an appropriate configuration.
15. A radio frequency identification (“RFID”) device, comprising:
send the DHCPDISCOVER request to a Dynamic Host Configuration Protocol (“DHCP”) server;
receive, via the network interface, provisioning information from the DHCP server that enables a desired functionality according to an identity and a location of the RFID reader, the provisioning information including second location information; and
provision the RFID reader according to the provisioning information, thereby enabling the RFID reader to read nearby RFID tags and to transmit RFID tag information and second location information to an RFID network.
16. A network for provisioning a device, the network comprising:
a radio frequency identification (“RFID”) device, comprising:
a memory having a computer program stored thereon, the computer program containing instructions for initializing the RFID device;
obtain first location data;
insert the first location data in an option field of a DHCPDISCOVER request; and
send, via the network interface, the DHCPDISCOVER request to a Dynamic Host Configuration Protocol (“DHCP”) server; and
a DHCP server, comprising:
an interface configured to receive the DHCPDISCOVER request; and
determine provisioning information, including a logical name, based at least in part on the first location data in the DHCPDISCOVER request; and
provide the provisioning information to the RFID device via the interface;
wherein the RFID device is further configured to do the following:
configure the device according to the provisioning information;
read RFID tag data from RFID tags; and
transmit the RFID tag data to a middleware server along with the logical name. Description
This application claims priority to U.S. Provisional Patent Application No. 60/570,999, entitled “Methods and Devices for Uniquely Provisioning RFID Devices” and filed on May 13, 2004, which is hereby incorporated by reference for all purposes. This application is related to U.S. patent application Ser. No. 10/866,506, entitled “Methods and Devices for Uniquely Provisioning RFID Devices” and filed on Jun. 9, 2004, to U.S. patent application Ser. No. 10/866,507, entitled “Methods and Devices for Locating and Uniquely Provisioning RFID Devices” and filed on Jun. 9, 2004, to U.S. patent application Ser. No. 10/866,285, entitled “Methods and Devices for Assigning RFID Device Personality” and filed on Jun. 9, 2004, to U.S. patent application Ser. No. 10/891,238, entitled “Methods and Devices for Determining the Status of a Device” and filed on Jul. 13, 2004, to U.S. patent application Ser. No. 10/876,410, entitled “System and Method for Automatically Configuring Switch Ports with Appropriate Features” and filed Jul. 21, 2004, to U.S. patent application Ser. No. 11/010,089, entitled “Methods and Devices for Providing Scalable RFID Networks” and filed on Dec. 9, 2004, to U.S. patent application Ser. No. 11/104,140, filed on Apr. 11, 2005, entitled “Automated Configuration of Network Device Ports” and to U.S. patent application Ser. No. 11/119,169, filed on Apr. 29, 2005, entitled “Locating and Provisioning Devices in a Network” (collectively, the “Cross-Referenced Applications”), all of which are hereby incorporated by reference for all purposes.
The present invention relates to provisioning devices in a network.
Most RFID tags use one of the Electronic Product Code (“EPC” or “ePC”) formats for encoding information. EPC codes may be formed in various lengths (common formats are 64, 96 and 128 bits) and have various types of defined fields, which allow for identification of, e.g., individual products as well as associated information. These formats are defined in various documents in the public domain. One such document is EPC Tag Data Standards Version 1.1 Rev 1.24 (EPCglobal� 2004), which is hereby incorporated by reference for all purposes.
One exemplary RFID tag format is shown in FIG. 1. Here, EPC 120 includes header 130, EPC Manager field 140, Object class field 150 and serial number field 160. EPC Manager field 140 contains manufacturer information. Object class field 150 includes a product's stock-keeping unit (“SKU”) number. Serial number field 160 is a 40-bit field that can uniquely identify the specific instance of an individual product i.e., not just a make or model, but also down to a specific “serial number” of a make and model.
In addition, RFID devices are being deployed with “static” knowledge of where the device was deployed at the original time of deployment. In practice, RFID devices are moved if another device is damaged or not functioning. In general, it is desirable to allow for the movement of RFID devices. However, if an RFID device is moved, prior art systems do not know to what location the RFID device has been moved.
Methods and devices are provided for locating, identifying and provisioning devices in a network. According to some implementations of the invention, a combination of EPC code information and existing networking standards form the basis of identifying and provisioning methods. For example, MAC address information and EPC information can be combined to identify a particular device and its location in a network. Upper-level applications can be notified, for example, that a particular device is available for use.
For implementations using the Dynamic Host Configuration Protocol (“DHCP”), DHCP Options may be used to pass identification, location and provisioning information. For example, selected DHCP Options may be used to indicate a device type, to provide an EPC code uniquely identifying the particular device, indicating the company name using the device and indicating how the device is being used.
In some implementations of the invention, location information included in a DHCPDISCOVER request can be used to determine appropriate configurations for networked devices. In some such implementations, the location information is read from an RFID tag near the networked device and is inserted in the DHCPDISCOVER request. 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. Some such implementations of the invention use DHCPINFORM (RFC 2131) and DHCP Options (RFCs 2132 and 3004) to pass current provisioning and personality information. Moreover, some such implementations of the invention use the DHCPFORCERENEW command (RFC 3203) from a DHCP server to initiate an update or to complete reconfiguration, as required.
Some implementations of the invention provide a method of provisioning a device. The method includes these steps: initializing an RFID device; reading RFID tag data from an RFID tag; inserting the RFID tag data in an option field of a DHCPDISCOVER request; sending the DHCPDISCOVER request to a DHCP server; ascertaining, based at least in part on the RFID tag data, a location and a logical name of the RFID device; determining, based in part on the location of the RFID device, an appropriate configuration for the RFID device; and provisioning the RFID device according to the appropriate configuration, wherein the provisioning step comprises provisioning the RFID device with a logical name.
The RFID device may be, for example, a wireless RFID device. The ascertaining step may involve accessing a data structure that includes RFID tag data and corresponding location data and logical names. At least part of the ascertaining step may be performed by the DHCP server.
Some aspects of the invention provide methods of provisioning a wireless device. Some such methods include these steps: receiving IEEE 802.11b location data from a plurality of wireless access points; ascertaining, based at least in part on the IEEE 802.11b location data, a location and a logical name of a wireless device; determining an appropriate configuration for the wireless device according to the location; and provisioning the wireless device, wherein the configuring step comprises supplying the wireless device with the appropriate configuration and with a logical name.
The wireless device may be, for example, a manufacturing device, an RFID device, a portable digital assistant or a laptop computer. The IEEE 802.11b location data could be, for example, time data, signal strength data or both.
Alternative methods for provisioning a device are also provided. Some such methods include these steps: receiving a DHCP request; ascertaining a location and a logical name of a device according to information in the DHCP request; determining, based at least in part on the location, an appropriate configuration for the device; and providing the device with the appropriate configuration and with a logical name.
The ascertaining step may involve determining a location encoded in the DHCP request. The ascertaining step may involve accessing a data structure and mapping the information in the DHCP request to corresponding location data.
Another aspect of the invention provides a method for deploying a uniquely-provisioned RFID device in a network. The method includes these steps: reading first location information from a first RFID tag; forming a DHCPDISCOVER request that includes an electronic product code of an RFID reader and the first location information; sending the DHCPDISCOVER request to a DHCP server; receiving provisioning information from the DHCP server that enables a desired functionality according to an identity and a location of the RFID reader, the provisioning information including second location information; and provisioning the RFID reader according to the provisioning information, thereby enabling the RFID reader to read nearby RFID tags and to transmit RFID tag information and second location information to an RFID network.
The first location information may be, for example, cartographic information such as coordinate information, latitude/longitude or civil address information. The second location information may include a logical name.
Some embodiments of the invention provide a network, comprising: a plurality of RFID devices; a plurality of switches connecting the RFID devices to the network; and a DHCP server. At least some of the RFID devices include these elements: means for reading first location information from a first RFID tag; means for forming a DHCPDISCOVER request that includes an electronic product code (“EPC”) of an RFID reader and the first location information; means for sending the DHCPDISCOVER request to a DHCP server; means for receiving provisioning information from the DHCP server that enables a desired functionality according to an identity and a location of the RFID reader, the provisioning information including second location information; and means for provisioning the RFID reader according to the provisioning information, thereby enabling the RFID reader to read nearby RFID tags and to transmit RFID tag information and second location information to an RFID network.
The DHCP server includes these elements: means for receiving the DHCPDISCOVER request; means for automatically identifying an RFID device according to a media access control address and an EPC included in the DHCPDISCOVER request; means for locating the RFID device and determining the second location information according to the first location information included in the DHCPDISCOVER request; and means for providing the RFID device with a desired functionality and the second location information.
Some aspects of the invention provide yet another method of provisioning a device. The method includes these steps: initializing an RFID device; obtaining first location data; inserting the first location data in an option field of a DHCPDISCOVER request; sending the DHCPDISCOVER request to a Dynamic Host Configuration Protocol (“DHCP”)server; determining provisioning information, including a logical name, based at least in part on the first location data; providing the provisioning information to the device; configuring the device according to the provisioning information; reading RFID tag data from RFID tags; and transmitting the RFID tag data to a middleware server along with the logical name. In some implementations, the RFID device includes global positioning system (“GPS”) capability and the first location data comprise GPS data. The methods of the present invention may be implemented, at least in part, by hardware and/or software. For example, some embodiments of the invention provide computer programs embodied in machine-readable media. The computer programs include instructions for controlling one or more devices to perform the methods described herein.
FIG. 9A is a network diagram that illustrates an alternative embodiment of the invention.
FIG. 9B illustrates a Global Location Number (“GLN”).
FIG. 9C illustrates one exemplary location reference field of the GLN illustrated in FIG. 9B.
FIG. 10 is a flow chart that outlines an alternative method of the invention.
FIG. 11 is a network diagram that illustrates another embodiment of the invention.
FIG. 12 is a flow chart that outlines yet another method of the invention.
FIG. 13 illustrates one exemplary format of an RFID read that includes a logical device name and device location data.
FIG. 14 is a flow chart that outlines another aspect of the present invention.
FIG. 15 illustrates an example of a network device that may be configured to implement some methods of the present invention.
Although the present invention involves methods and devices for locating, identifying and provisioning individual RFID devices in a network, many aspects of the present invention can be applied to identifying and provisioning other types of devices in a network. For example, the present invention may also be used for locating, identifying and provisioning manufacturing devices, networked sensor devices, IPphones, portable digital assistants and other networked devices, including wireless and wired devices. Similarly, although much of the discussion herein applies to implementations using the DHCP protocol, the present invention is not protocol-specific and may be used, for example, in implementations using UPnP, 802.1ab or similar discovery protocols. Likewise, while the implementations described herein refer to exemplary DHCP Options, other DHCP Options may advantageously be used to implement the present invention.
In this illustration, products 227 are being delivered to warehouse 201 by truck 275. Products 227, which already include RFID tags, are delivered through door 223. In this example, RFID reader 252 is connected to port 262 of switch 260. Here, switches 230 and 260 are connected to the rest of RFID network 200 via gateway 250 and network 225. Network 225 could be any convenient network, but in this example network 225 is the Internet. RFID reader 252 reads each product that passes through door 223 and transmits the EPC code corresponding to each product on RFID network 200.
Each of the RFID devices in network 200 preferably has a “personality” suitable for its intended use. For example, device 252 could cause reassuring tone to sound and/or a green light to flash if an authorized person or object enters door 223. However, device 252 might cause an alarm to sound and/or an alert to be sent to an administrator on network 200 if a product exits door 223 or an unauthorized person enters or exits door 223.
However, in preferred implementations, such information is only stored in volatile memory 315 after being received from, e.g. a DHCP server. There are advantages to keeping RFID devices “dumb.” For example, a network of dumb RFID devices allows much of the processing load to be centralized (e.g., performed by server 270 of network 200), instead of being performed by the RFID devices. Alternatively, the processing load can be decentralized, but only to trusted devices (such as PC 247 of network 200).
An overview of some such implementations of the present invention will now be described with reference to FIG. 6. It will be appreciated by those of skill in the art that the steps illustrated and described herein are not necessarily performed in the order indicated. Moreover, it will be appreciated that some aspects of the invention may be performed using more (or fewer) steps than are indicated herein. A device that sends out an initiation for an IP address to a DHCP server does so by way of a packet that includes a “DHCPDISCOVER” request. This command includes the media access control (“MAC”) address of the device. According to some preferred implementations, the RFID device (e.g., CPU 310 of RFID Reader 300) forms a “DHCPDISCOVER” request packet that includes information in various DHCP Option fields (step 601). The RFID device encodes DHCP “vendor class identifier” Option 60 with a code indicating that the device is an RFID device. In other words, “RFID” will be a new type of “vendor class,” encoded in Option 60.
In this example, the RFID device encodes its own EPC in the field reserved for Option 43 (vendor specific information, defined in RFC 2132), Option 61 or Option 125 (vendor-identifying vendor specific information, defined in RFC 3925). The RFID device also encodes a company name, e.g., of the company that supplies, owns or is using the RFID device, in DHCP Option 43.
Option 77 (user class option, defined in RFC 3004) or Option 124 (vendor-identifying class option, defined in RFC 3925) may be used in various ways according to different implementations of the invention. In some implementations, Option 77 or Option 124 will be used to indicate the type of RFID device, e.g., that the RFID device is an RFID reader or an RFID printer. In some implementations, Option 77 or Option 124 can also include information regarding the functionality or “personality” of the RFID device. For example, Option 77 or Option 124 could indicate that the RFID device is an inbound RFID reader, an outbound RFID reader, an RFID reader or printer on an assembly line, a retail store, etc.
Referring once again to FIG. 2, if the request is from RFID device 252, that device would encode information in Option 77 or Option 124 indicating that the device is an RFID reader. In some implementations, Option 77 or Option 124 also indicates that RFID device 252 has a personality suitable for being positioned at an entrance door. Some implementations include more detailed information about the current personality of device 252. For example, Option 77 or Option 124 may indicate that in addition to reading EPC codes and uploading them to the RFID network, device 252 will also cause a green light to flash if an authorized person or object enters door 223 and will cause a red light to flash, an alarm to sound and an alert to be sent to an administrator on the network if a product exits door 223. This information could be encoded, for example, according to a number that corresponds to one of a range of suitable personalities for an RFID reader at an entrance door.
Some such implementations use DHCP Option 82 (RFC 3046) in a new way to determine the switch port and switch to which an RFID device is connected. For example, a switch may insert the following two information elements into any DHCP request from an attached RFID device: Option 82, Sub-Option 1: Agent Circuit ID and Option 82, Sub-Optionb 2: Agent Remote ID. The Agent Circuit ID is the name or identifier of the switch. The Agent Remote ID is the name or identifier of the switch port.
According to some implementations, step 630 involves setting the DHCP Ti timer for a short time interval, for example, 60 seconds. In this example, the RFID device will continue to send DHCP requests to the server every 60 seconds and the server will send “ACKs” to the device until one of two events occurs: (1) the server has been updated (e.g., by IT personnel responsible for the site within which the RFID device is located); or (2) the connection between the server and the RFID device goes down. (Step 635.)
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.
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.
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 FIG. 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. 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 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 implementing the present invention. 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 the invention. 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 of the invention, 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 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 maybe 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. 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. In 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” (draft-ietf-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 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. 9A. 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 implementations, wireless device 1105 may be 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.11b 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.11b location data” or the like.
Such IEEE 802.11b 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.11b 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.11b location data into the location frames received from wireless device 1105 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.
In step 1225, management server 1120 attempts to determine the location of wireless device 1105 using the IEEE 802.11b 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.11b 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. 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.
In 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. 9A 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 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 (“dockDoor100”) and latitude/longitude/altitude data, as follows:
<?xml version=“1.0” encoding=“UTF-8”>
. . . <rfidReader>
<readerName name=“dockDoor100”>
<readerLocation>
<locationCoordinates>
<lattitude>053C1F751</lattitude>
<longitude>F50BA5B97</longitude>
<altitude>00006700</altitude>
</locationCoordinates>
</readerLocation>
<readPoint id=“1”>
<epc >000000000000000000000001</epc>
</readerName>
</rfidReader>
Within the XML document, there is a single EPC tag read value (“<epc>00000000000000000000000</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 aspects of the invention. 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 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 aspects of the invention the read is associated with a location and/or a function via a logical name such as “dock door A,” “Building 22, 3rd 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 methods of the present invention. Network device 1560 includes a master central 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 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, FDDI interfaces, ASI interfaces, DHEI interfaces and the like.
When acting under the control of appropriate software or firmware, in some implementations of the invention 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.
Although the system shown in FIG. 15 illustrates one specific network device of the present invention, it is by no means the only network device architecture on which the present invention 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).
Patent CitationsCited PatentFiling datePublication dateApplicantTitleUS4688026Apr 21, 1986Aug 18, 1987Scribner James RMethod of collecting and using data associated with tagged objectsUS5339073Mar 25, 1991Aug 16, 1994Identec LimitedAccess control equipment and method for using the sameUS5574722Mar 21, 1995Nov 12, 1996Bay Networks, Inc.Protocol independent switchUS5646616Jun 26, 1995Jul 8, 1997Murata Kikai Kabushiki KaishaPicking systemUS5819042Feb 20, 1996Oct 6, 1998Compaq Computer CorporationMethod and apparatus for guided configuration of unconfigured network and internetwork devicesUS5832503Feb 24, 1995Nov 3, 1998Cabletron Systems, Inc.Method and apparatus for configuration management in communications networksUS5850187Mar 27, 1996Dec 15, 1998Amtech CorporationIntegrated electronic tag reader and wireless communication linkUS5887176Jun 28, 1996Mar 23, 1999Randtec, Inc.Method and system for remote monitoring and tracking of inventoryUS6070187Mar 26, 1998May 30, 2000Hewlett-Packard CompanyMethod and apparatus for configuring a network node to be its own gatewayUS6111517Dec 30, 1996Aug 29, 2000Visionics CorporationContinuous video monitoring using face recognition for access controlUS6115079Feb 14, 1998Sep 5, 2000Mcrae; Michael W.Programmable video channel controllerUS6300903Dec 8, 1999Oct 9, 2001Time Domain CorporationSystem and method for person or object position location utilizing impulse radioUS6539281Apr 23, 2001Mar 25, 2003Accenture Global Services GmbhOnline medicine cabinetUS6553489Jan 12, 2000Apr 22, 2003Cisco Technology, Inc.System and method for secure and efficient universal port configurationUS6587874Jun 29, 1999Jul 1, 2003Cisco Technology, Inc.Directory assisted autoinstall of network devicesUS6665713Jun 6, 2000Dec 16, 2003Nec CorporationTopology information automatic configuration method and its topology information automatic configuration systemUS6772204Oct 5, 1998Aug 3, 2004Hewlett-Packard Development Company, L.P.Method and apparatus of providing a configuration script that uses connection rules to produce a configuration file or map for configuring a network deviceUS6810040Dec 22, 1997Oct 26, 2004Cisco Technology, Inc.Method and apparatus for configuring network devicesUS6843121Aug 25, 2003Jan 18, 2005Eastman Kodak CompanyMeasuring absolute static pressure at one or more positions along a microfluidic deviceUS6963282Dec 5, 2003Nov 8, 2005Microsoft CorporationWireless self-describing buildingsUS7002907Jul 26, 2001Feb 21, 2006Ciena CorporationSystem and methods for automatic equipment provisioning for SONET networksUS7038573Sep 8, 2003May 2, 2006Single Chip Systems CorporationSystems and methods for tracking the location of items within a controlled areaUS7054924Sep 29, 2000May 30, 2006Cisco Technology, Inc.Method and apparatus for provisioning network devices using instructions in extensible markup languageUS7057511Feb 12, 2002Jun 6, 2006Symbol Technologies, Inc.Method, system, and apparatus for communicating with a RFID tag populationUS7064660May 14, 2002Jun 20, 2006Motorola, Inc.System and method for inferring an electronic rendering of an environmentUS7075412May 29, 2003Jul 11, 2006Thingmagic L.L.C.Methods and apparatus for operating a radio deviceUS7081819Jul 9, 2003Jul 25, 2006Neology, Inc.System and method for providing secure identification solutionsUS7103040 *Nov 19, 2001Sep 5, 2006Telefonaktieboaget Lm Ericsson (Publ)Method and apparatus for identifying a node for data communications using its geographical locationUS7103886Oct 19, 2001Sep 5, 2006Sap AgSystem, method, computer program product for communicating data for objects that are transported from first location to second locationUS7120139Dec 30, 1999Oct 10, 2006At&T Corp.Broadband cable telephony network architecture IP ITN network architecture reference modelUS7129837Apr 8, 2004Oct 31, 2006Savi Technology, Inc.Continuous security state tracking for intermodal containers transported through a global supply chainUS7165722Mar 10, 2004Jan 23, 2007Microsoft CorporationMethod and system for communicating with identification tagsUS7205897Mar 1, 2005Apr 17, 2007Sap AktiengesellschaftProduct flow based auto-ID infrastructureUS7213768Mar 16, 2005May 8, 2007Cisco Technology, Inc.Multiple device and/or user associationUS7242303Mar 4, 2005Jul 10, 2007Cisco Technology, Inc.Navigation and coordination during emergenciesUS7249170Dec 6, 2000Jul 24, 2007IntellidenSystem and method for configuration, management and monitoring of network resourcesUS7322523Jun 9, 2004Jan 29, 2008Cisco Technology, Inc.Methods and devices for uniquely provisioning RFID devicesUS7323988Dec 17, 2004Jan 29, 2008Alcatel LucentPersonal item reminderUS7325734Jun 9, 2004Feb 5, 2008Cisco Technology, Inc.Methods and devices for assigning RFID device personalityUS7336175Jun 9, 2004Feb 26, 2008Cisco Technology, Inc.Methods and devices for locating and uniquely provisioning RFID devicesUS7345585Aug 1, 2005Mar 18, 2008Cisco Technology, Inc.Network based device for providing RFID middleware functionalityUS7394381May 6, 2004Jul 1, 2008Ut-Battelle, LlcMarine asset security and tracking (MAST) systemUS7411915Jul 21, 2004Aug 12, 2008Cisco Technology, Inc.Automatically configuring switch ports with appropriate featuresUS7422152Dec 9, 2004Sep 9, 2008Cisco Technology, Inc.Methods and devices for providing scalable RFID networksUS20010012292Apr 11, 1997Aug 9, 2001Todd A. MerrillRouter for use with a link that has a set of concurrent channelsUS20010028308Apr 11, 2001Oct 11, 2001Carlos De La HuergaInteractive medication containerUS20020014964Dec 21, 2000Feb 7, 2002Eiji OkamuraInventory control systemUS20020016739Oct 9, 2001Feb 7, 2002Fujitsu LimitedSystem and method for managing expiration-dated products utilizing an electronic receiptUS20020075805Sep 13, 2001Jun 20, 2002Narad Networks, Inc.Broadband system with QOS based packet handlingUS20020161907Apr 24, 2002Oct 31, 2002Avery MoonAdaptive multi-protocol communications systemUS20030046339Sep 5, 2001Mar 6, 2003Ip Johnny Chong ChingSystem and method for determining location and status of computer system serverUS20030084279Oct 29, 2001May 1, 2003Pitney Bowes Inc.Monitoring system for a corporate networkUS20030174714Mar 3, 2003Sep 18, 2003Globespan Virata, Inc.Zero-installation PPP-Bridge setup for lan-to-wan connectivityUS20040021569Nov 21, 2001Feb 5, 2004Robert LepkofkerPersonnel and resource tracking method and system for enclosed spacesUS20040061646Sep 30, 2002Apr 1, 2004Lucent Technologies, Inc.Methods and apparatus for location determination based on dispersed radio frequency tagsUS20040069852Jun 25, 2003Apr 15, 2004Nokia CorporationBluetooth RF based RF-tag read/write stationUS20040100383Nov 21, 2002May 27, 2004Kimberly-Clark Worldwide, Inc.RFID system and method for ensuring safety of hazardous or dangerous substancesUS20040108795Dec 6, 2002Jun 10, 2004Meek Robert B.High capacity drawer with mechanical indicator for a dispensing deviceUS20040128389Dec 31, 2002Jul 1, 2004Kurt KopchikMethod and apparatus for wirelessly establishing user preference settings on a computerUS20040257202Jun 16, 2004Dec 23, 2004Coughlin Michael E.RFID tag and method of user verificationUS20050021626May 22, 2003Jan 27, 2005Cisco Technology, Inc.Peer-to-peer dynamic web page sharingUS20050027778Jul 29, 2003Feb 3, 2005Arthur DimitrelisAutomatic configuration of an address allocation mechanism in a computer networkUS20050060208Aug 17, 2004Mar 17, 2005Gianantoni Raymond J.Method for optimizing insurance estimates utilizing Monte Carlo simulationUS20050093679Oct 29, 2004May 5, 2005Zai Li-Cheng R.Method and system of using active RFID tags to provide a reliable and secure RFID systemUS20050099270Nov 10, 2004May 12, 2005Impinj, Inc.RFID tags adjusting to different regulatory environments, and RFID readers to so adjust them and methodsUS20050199716Mar 10, 2004Sep 15, 2005Microsoft CorporationMethod and system for communicating with identification tagsUS20050209947Mar 10, 2004Sep 22, 2005Microsoft CorporationMethod and identification tag for asset managementUS20050252957Jun 9, 2004Nov 17, 2005Cisco Technology, Inc.Methods and devices for locating and uniquely provisioning RFID devicesUS20050252970Jun 9, 2004Nov 17, 2005Cisco Technology, Inc.Methods and devices for uniquely provisioning RFID devicesUS20050252971Dec 9, 2004Nov 17, 2005Cisco Technology, Inc.,Methods and devices for providing scalable RFID networksUS20050253717Jun 9, 2004Nov 17, 2005Cisco Technology, Inc.Methods and devices for assigning RFID device personalityUS20050253718Apr 29, 2005Nov 17, 2005Cisco Technology, Inc., A Corporation Of CaliforniaLocating and provisioning devices in a networkUS20050253722May 12, 2005Nov 17, 2005Cisco Technology, Inc.Locating, provisioning and identifying devices in a networkUS20050264420Apr 11, 2005Dec 1, 2005Cisco Technology, Inc. A Corporation Of CaliforniaAutomated configuration of network device portsUS20060005035Oct 8, 2004Jan 5, 2006Coughlin Michael EKeystroke input device for use with an RFID tag and user verification systemUS20060010086Jun 1, 2005Jan 12, 2006Klein Elliot SData append method for sent postal mailUS20060031374Sep 2, 2005Feb 9, 2006Transtech Networks Usa, Inc.Packet switch and method thereof dependent on application contentUS20060033606Jul 13, 2004Feb 16, 2006Cisco Technology, Inc. A Corporation Of CaliforniaMethods and apparatus for determining the status of a deviceUS20060044111Feb 24, 2003Mar 2, 2006Jafa Technologies., Inc.,Real-time data reporting using radio frequency identificationUS20060071790Sep 29, 2004Apr 6, 2006Duron Mark WReverse infrastructure location system and methodUS20060091999Dec 13, 2005May 4, 2006Cisco Technology, Inc., A Corporation Of CaliforniaUsing syslog and SNMP for scalable monitoring of networked devicesUS20060143318Dec 29, 2004Jun 29, 2006Cisco Technology, Inc., A Corporation Of CaliforniaAgnostic peripheral control for media communication appliancesUS20060253590Apr 5, 2006Nov 9, 2006Konaware, Inc.Platform and methods for continuous asset location tracking and monitoring in intermittently connected environmentsUS20060266832Jul 31, 2006Nov 30, 2006Cisco Technology, Inc.Virtual readers for scalable RFID infrastructuresUS20070013518Jul 14, 2005Jan 18, 2007Cisco Technology, Inc.Provisioning and redundancy for RFID middleware serversUS20070027966Aug 1, 2005Feb 1, 2007Cisco Technology, Inc.Network based device for providing RFID middleware functionalityUS20070080784Jul 17, 2006Apr 12, 2007Electronics And Telecommunications Research InstituteMobile RFID service providing apparatus and method thereofUS20070229274May 30, 2007Oct 4, 2007Cisco Technology, Inc.Navigation and coordination during emergenciesUS20080104209Dec 27, 2007May 1, 2008Cisco Technology, Inc.Network based device for providing rfid middleware functionalityWO2005060208A1Dec 16, 2003Jun 30, 2005Ericsson Telefon Ab L MEthernet dsl access multiplexer and method providing dynamic service selection and end-user configurationWO2005114545A2May 10, 2005Dec 1, 2005Cisco Tech IndMethods and devices for locating and provisioning rfid devices and related network devicesWO2005114602A2Apr 29, 2005Dec 1, 2005Cisco Tech IndMethods and devices for assigning rfid device personalityWO2005114603A2May 10, 2005Dec 1, 2005Cisco Tech IndLocating and provisioning devices in a networkWO2005114604A2May 13, 2005Dec 1, 2005Cisco Tech IndLocating, provisioning and identifying devices in a networkWO2007011591A2Jul 11, 2006Jan 25, 2007Cisco Tech IncProvisioning and redundancy for rfid middleware serversWO2008016488A2Jul 18, 2007Feb 7, 2008Cisco Tech IncVirtual readers for scalable rfid infrastructures* Cited by examinerNon-Patent CitationsReference1"Cisco Application-Oriented Networking: A Network-Based Intelligent Message Routing System", http://www.cisco.com/en/US/products/ps6438/products-data-sheet0900aecd802c1f9c.html Data Sheet, Cisco Systems, Inc., Jul. 13, 2005, pp. 1-7.2"Cisco Application-Oriented Networking-A Network Embedded Intelligent Message Routing System", http://www.cisco.com/en/US/products/ps6438/prod-bulletin0900aecd802c201b.html Product Bulletin No. 2886, Cisco Systems, Inc. Jul. 13, 2005, pp. 1-3.3"Cisco Catalyst 6500 Series Application-Oriented Networking Module", http://www.cisco.com/en/US/products/ps6438/products-data-sheet0900aecd802c1fe9.html Data Sheet, Cisco Systems, Inc. Jul. 13, 2005, pp. 1-3.4"Cisco Catalyst 6500 Series Application-Oriented Networking Module: Large Photo", Photo, Retrieved from the internet: http://www.cisco.com/en/US/products/ps6448/prod-view-selector.html [Retrieved Jul. 13, 2007], Cisco Systems, Inc. 1 page.5"The EPCglobal Architecture Framework" EPCglobal Final Version of Jul. 1, 2005, pp. 1-53.6"Cisco Application-Oriented Networking: A Network-Based Intelligent Message Routing System", http://www.cisco.com/en/US/products/ps6438/products—data—sheet0900aecd802c1f9c.html Data Sheet, Cisco Systems, Inc., Jul. 13, 2005, pp. 1-7.7"Cisco Application-Oriented Networking—A Network Embedded Intelligent Message Routing System", http://www.cisco.com/en/US/products/ps6438/prod—bulletin0900aecd802c201b.html Product Bulletin No. 2886, Cisco Systems, Inc. Jul. 13, 2005, pp. 1-3.8"Cisco Catalyst 6500 Series Application-Oriented Networking Module: Large Photo", Photo, Retrieved from the internet: http://www.cisco.com/en/US/products/ps6448/prod—view—selector.html [Retrieved Jul. 13, 2007], Cisco Systems, Inc. 1 page.9"Cisco Catalyst 6500 Series Application-Oriented Networking Module", http://www.cisco.com/en/US/products/ps6438/products—data—sheet0900aecd802c1fe9.html Data Sheet, Cisco Systems, Inc. Jul. 13, 2005, pp. 1-3.10AeroScout Visibility System: Bridging the Gap Between Wi-Fi, Active RFID and Telemetry, AeroScout Enterprise Visibility Solutions, http://www.aeroscout.com/content.asp?page=SystemOverview, printed Apr. 16, 2005, 3 pages.11Australian Office Action dated Apr. 17, 2009 from Application No. 2005246794; 2 pgs.12Biloruset, Ruslan et al., "Web Services Reliable Messaging Protocol (WS-ReliableMessaging)", Mar. 2004, pp. 1-40.13Chinese Office Action (third) dated Feb. 20, 2009 issued in CN1954327 [CN200580015167.4 - P377CN].14Chinese Office Action dated Jun. 27, 2008 issued in CN200580031604.01.15EPCgl, Frequently Asked Questions, http://www.epcglobalinc.com/about/faqs.html, printed Mar. 24, 2005, 9 pages.16EPCTM Tag Data Standards Version 1.1 Rev.1.24, EPCglobal, Standard Specification, Apr. 1, 2004, 78 pages.17European Examination Report dated Sep. 18, 2008 issued in EP06739488 [P412EP].18Final Office Action mailed Oct. 6, 2008 from U.S. Appl. No. 11/104,140.19First Office Action from the Chinese Patent Application No. 200580015167.4 issued on Feb. 29, 2008.20First Office Action from the Chinese Patent Application No. 200580015168.9 issued on Feb. 29, 2008.21First Office Action from the Chinese Patent Application No. 200580015169.3 issued on Feb. 29, 2008.22Fujitsu Limited, et al., "Web Services Reliability (WS-Reliability) Ver1.0", Jan. 8, 2003. pp. 1-45.23G. Stump et al., The User Class Option for DHCP, http://www.ietf.org/rfc/, IBM, Nov. 2000 (RFC 3004), printed Mar. 24, 2005, 6 pages.24Girardot, Marc and Sundaresan, Neel, "Millau: an encoding format for efficient representation and exchange of XML over the web" [Retrieved Jan. 31, 2005]. Retrieved from the internet: http:www9.org/w9cdrom/154/154.html 25 pages.25Global Location Number (GLN) Implementation Guide, Uniform Code Council, Inc., May 2002, 13 pages.26H. Schulzrinne, Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information draft-ietf-geopriv-dhcp-civil-05, Columbia University, Feb. 19, 2004.27Harrington, D., et al, An Architecture for DescribingSimple Network Management Protocol (SNMP) Management Frameworks, RFC 3411, Dec. 2002, 64 pages.28International Preliminary Report on Patentability mailed Nov. 23, 2006, Applcation No. PCT/US2005/016484.29International Preliminary Report on Patentability mailed Nov. 23, 2006, Application No. PCT/US2005/015322.30International Preliminary Report on Patentability mailed Nov. 23, 2006, Application No. PCT/US2005/016319.31International Preliminary Report on Patentability mailed Oct. 11, 2007, Application No. PCT/US2005/016958.32international Search Report dated Feb. 17, 2006, from related International Application No. PCT/US05/15322, 5 pp. including Notification of Transmittal.33International Search Report dated Jul. 13, 2006, from (related) International Application No. PCT/US05/16319, 5 pp. including Notification of Transmittal.34International Search Report dated Oct. 13, 2005, from (related) International Application No. PCT/US05/16484, 6 pp. including Notification of Transmittal.35International Search Report mailed Sep. 12, 2007 from International Application No. PCT/US05/16958 including Notification of Transmittal; Written Opinion of Searching Authority mailed Sep. 12, 2007 from International Application No. PCT/US05/16958 p. 8.36International Searching Authority, "Notification of Transmittal of the International Search Report of the International Searching Authority, or the Declaration," PCT/US06/, dated Mar. 6, 2008, 14 pages.37International Searching Authority, "Notification of Transmittal of the International Search Report or the Declaration," PCT/US07/16321, dated May 19, 2008, 11 pages.38International Searching Authority, "Written Opinion of the International Searching Authority" PCT/US07/16321, dated May 19, 2008, 11 pages.39International Searching Authority, "Written Opinion of the International Searching Authority," PCT/US06/, dated Mar. 6, 2008, 14 pages.40J. Littlefield, Vendor-Identifying Vendor Options for Dynamic Host Configuration Protocol version 4 (DPHCPv4), Network Working Group, Request for Comments: 3925, Category: Standards Track, Cisco Systems, Inc., Oct. 2004, 9 pages.41J. Polk et al., Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information, Network Working Group, Request for Comments: 3825, Category: Standards Track, Cisco Systems, Jul. 2004, 15 pages.42Kanellos, "Newsmaker: Making sense of sensors, " CNET News.com:news.com.com/Making +sense+of+sensors/ 2008-1082— 3-5829415.html, Published: Aug. 12, 2005.43Lonvick, C., The BSD Syslog Protocol, RFC 3164, Aug. 2001, 28 pages.44M Johnston, DHCP Preboot Execution Environment (PXE) Options draft-ietf-dhc-pxe-options-01.txt, Dynamic Host Configuration Working Group, Intel Coporation, Jan. 21, 2005, 7 pages.45M. Patrick, DHCP Relay Agent Information Option, http://www.ietf.org/rfc/, Motorola BCS, JAn. 2001 (RFC 3046), printed Mar. 24, 2005, 14 pages.46Mockapetris, P., "Domain Names-Concepts and Facillities", RFC 1034, Nov. 1987, 43 pages.47Mockapetris, P., "Domain Names-Implementation and Specification", RFC 1035, 55 pages.48Mockapetris, P., "Domain Names—Concepts and Facillities", RFC 1034, Nov. 1987, 43 pages.49Mockapetris, P., "Domain Names—Implementation and Specification", RFC 1035, 55 pages.50Mohl, Dirk S., "IEEE 1588: Running Real-Time on Ethernet," retrieved from the Internet: <URL:http//ethernet.industrial-networking.com/articles/i17 real-time.asp>. cited by other.51Montague, Jim, "Ethernet Hits Real-Time ... Really," Control Engineering, Dec. 1, 2003, copyright 2004 Reed Business Information, a division of Reed Elsevier Inc.; retrieved from the Internet: <URL:http://www.manufacturing.net/ctl/iindex.asp?dlayout=articlePrint&- articlelD=CA339683>. cited by other.52Notice of Allowance and Notice of Allowability, mailed Mar. 12, 2007 from U.S.Appl. No. 11/073,245.53Notice of Allowance and Notice of Allowability, mailed Oct. 11, 2007 from U.S. Appl. No. 11/010,089.54Notice of Allowance and Notice of Allowability, mailed Sep. 10, 2007 from U.S. Appl. No. 10/866,285.55Notice of Allowance and Notice of Allowability, mailed Sep. 10, 2007 from U.S. Appl. No. 10/866,506.56Notice of Allowance and Notice of Allowability, mailed Sep. 19, 2007 from U.S. Appl. No. 11/195,160.57Notice of Allowance and Notice of Allowability, mailed Sep. 28, 2007 from U.S. Appl. No. 10/866,507.58Office Action (Restriction Requirement) mailed Apr. 1, 2008 from U.S. Appl. No. 11/119,169.59Office Action from Canadian Patent Application No. 2,565,099 issued Feb. 4, 2008.60Office Action from Canadian Patent Application No. 2,565,456 issued on Feb. 1, 2008.61Office Action from the Canadian Patent Application No. 2,565,099 mailed Nov. 17, 2008.62Office Action mailed Aug. 13, 2008 from U.S. Appl. No. 11/954,721.63Office Action mailed Aug. 6, 2008 from U.S. Appl. No. 11/119,169.64Office Action mailed May 12, 2008 from U.S. Appl. No. 11/104,140.65Office Action mailed Nov. 26, 2008 from U.S. Appl. No. 11/182,312.66PCT International Preliminary Examination Report dated Nov. 14, 2006 issued in WO2005114545 [PCT/US2005/016484].67PCT International Preliminary Examination Report dated Nov. 14, 2006 issued in WO2005-114603 [PCT/US2005/016319].68PCT International Search Report dated Jul. 13, 2006 issued in WO2005-114603 [PCT/US2005/016319].69PCT International Search Report dated Nov. 8, 2005 issued in WO2005-114545 [PCT/US2005/016484].70PCT International Search Report dated Sep. 12, 2007 issued in WO2005114604 [PCT/US2005/016958].71PCT Written Opinion dated Jul. 13, 2006 issued in WO2005-114603 [PCT/US2005/016319].72PCT Written Opinion dated Mar. 6, 2008 issued in WO2007011591 [PCT/US2006/026970].73PCT Written Opinion dated Nov. 8, 2005 issued in WO2005114545 [PCT/US2005/016484].74PCT Written Opinion dated Sep. 12, 2007 issued in WO2005114604 [PCT/US2005/016958].75Presuhn, R., Editor, Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP), RFC 3416, Dec. 2002, 31 pages.76R. Droms, Dynamic Host Configuration Protocol, http://www.ietf.org/rfc/, Bucknell University, Mar. 1997 (RFC 2131), printed Mar. 24, 2005, 43 pages.77R. Johnson, TFTP Server Address DHCP Option draft-raj-dhc-tftp-addr-option-11.txt, Network Working Group, Cisco Systems, Inc., Feb. 6, 2005, 7 pages.78S. Alexander et al., DHCP Options and BOOTP Vendor Extensions, http://www.ietf.org/rfc/, Silicon, Graphics, Inc., Mar. 1997 .(RFC 2132), printed Mar. 24, 2005, 32 pages.79Second Notice of Allowance and Notice of Allowability, mailed Jan. 11, 2008 from U.S. Appl. No. 11/010,089.80Second Office Action for CN Patent Application No. 200580015168.9 dated Aug. 15, 2008.81Second Office Action from the Chinese Patent Application No. 200580015167.4 mailed Aug. 15, 2008.82Second Office Action from the Chinese Patent Application No. 200580015169.3 mailed Aug. 15, 2008.83Simple Network Management Protocol, Internetworking Technologies Handbook, Chapter-56, printed Jul. 14, 2005, 12 pages.84Stump et al., "The User Class Option for DHCP," RFC 3004, Nov. 2000, 6 pages.85Supplemental Notice of Allowance and Notice of Allowability, mailed Oct. 22, 2007 from U.S. Appl. No. 11/195,160.86The Global Language of Business, retrieved from the internet: http://www.ean-int.org/locations.html, [retrieved Mar. 24, 2005], 5 pages.87U.S. Appl. No. 10/896,410, System and Method for Automatically Configuring Switch Ports With Appropriate Features, Spain et al., filed Jul. 21, 2004.88U.S. Appl. No. 11/954,721 as filed on Dec. 12, 2007, Methods and Devices for Assigning RFID Device Personality, Howarth et al.89U.S. Appl. No. 11/965,693 as filed on Dec. 27, 2007, Network Based Device for Providing RFID Middleware Functionality, Singhal et al.90U.S. Appl. No. 12/082,635, Methods and Devices for Providing Scalable RFID Networks, Howarth et al., filed Apr. 11, 2008.91U.S. Office Action (Restriction Requirement) mailed Jul. 28, 2008, for U.S. Appl. No. 11/182,312.92U.S. Office Action mailed Aug. 13, 2008, for U.S. Appl. No. 11/954,721.93U.S. Office Action mailed Mar. 3, 2008, for U.S. Appl. No. 11/809,139.94US Examiner's Amendment dated Nov. 7, 2007 issued in U.S. Appl. No. 11/195,160.95US Notice of Allowance and Examiner Amendment dated Mar. 27,2008 issued in U.S. Appl. No. 10/896,410.96US Notice of Allowance and Examiner's Amendment dated Feb. 11, 2009 issued in U.S. Appl. No. 11/119,169.97US Notice of Allowance dated Feb. 11, 2009 issued in U.S. Appl. No. 11/954,721.98US Notice of Allowance dated Jun 1,2009 issued in U.S. Appl. No. 11/954,721.99US Office Action dated Apr. 4, 2007 issued in U.S. Appl. No. 10/866,285.100US Office Action dated Aug. 9, 2006 issued in U.S. Appl. No. 10/866,507.101US Office Action dated Jan. 18, 2007 issued in U.S. Appl. No. 10/866,507.102US Office Action dated Jun. 18, 2007 issued in U.S. Appl. No. 11/010,089.103US Office Action dated Mar. 22, 2007 issued in U.S. Appl. No. 10/866,506.104US Office Action dated Mar. 31, 2009 issued in U.S. Appl. No. 11/304,944.105US Office Action dated Mar. 4, 2009 issued in U.S. Appl. No. 11/104,140.106US Office Action dated Oct. 10, 2007 issued in U.S. Appl. No. 10/896,410.107US Office Action dated Oct. 6, 2006 issued in U.S. Appl. No. 10/866,285.108US Office Action dated Oct. 6, 2006 issued in U.S. Appl. No. 10/866,506.109US Office Action mailed Apr. 4, 2007 from (related) U.S. Appl. No. 10/866,285.110US Office Action mailed Aug. 9, 2006 from (related) U.S. Appl. No. 10/866,507.111US Office Action mailed Jan. 18, 2007 from (related) U.S. Appl. No. 10/866,507, 4 pp.112US Office Action mailed Jun. 18, 2007 from (related) U.S. Appl. No. 11/010,089.113US Office Action mailed Jun. 26, 2007 from U.S. Appl. No. 11/195,160.114US Office Action mailed Mar. 22, 2007 from (related) U.S. Appl. No. 10/866,506.115US Office Action mailed Nov. 13, 2006 from (related) U.S. Appl. No. 11/073,245, 12 pp.116US Office Action mailed Oct. 6, 2006 from (related) U.S. Appl. No. 10/866,285.117US Office Action mailed Oct. 6, 2006 from (related) U.S. Appl. No. 10/866,506.118US Supplemental Notice of Allowance dated Oct. 22, 2007 issued in U.S. Appl. No. 11/195,160.119WhereNet, Products, http://wherenet.com/products-main.html, printed Apr. 16, 2005, 2 pages.120WhereNet, Products, http://wherenet.com/products—main.html, printed Apr. 16, 2005, 2 pages.121Written Opinion of the International Searching Authority dated Feb. 17, 2006, from related International Application No. PCT/US05/15322, 3 pp.122Written Opinion of the International Searching Authority dated Jul. 13, 2006, from (related) International Application No. PCT/US05/16319, 5 pp.123Written Opinion of the International Searching Authority dated Oct. 13, 2005, from (related) International Application No. PCT/US05/16484, 5 pp.124Y. T'Joens, DHCP Reconfigure Extension, http://www.ietf.org/rfc/, Alcatel, Dec. 2001, printed Mar. 24, 2005 (RFC 3203), 6 pages.Referenced byCiting PatentFiling datePublication dateApplicantTitleUS8060623Apr 11, 2005Nov 15, 2011Cisco Technology, Inc.Automated configuration of network device portsUS8086713 *Feb 6, 2009Dec 27, 2011Juniper Networks, Inc.Determining a subscriber device has failed gracelessly without issuing a DHCP release message and automatically releasing resources reserved for the subscriber device within a broadband network upon determining that another subscriber device requesting the reservation of a network address has the same context information as the failed subscriber deviceUS8113418Jul 31, 2006Feb 14, 2012Cisco Technology, Inc.Virtual readers for scalable RFID infrastructuresUS8249953 *Jul 13, 2004Aug 21, 2012Cisco Technology, Inc.Methods and apparatus for determining the status of a deviceUS8260902Jan 26, 2010Sep 4, 2012Juniper Networks, Inc.Tunneling DHCP options in authentication messagesUS8285875 *Mar 25, 2010Oct 9, 2012Juniper Networks, Inc.Synchronizing resource bindings within computer networkUS8560658Mar 23, 2010Oct 15, 2013Juniper Networks, Inc.Managing distributed address pools within network devicesUS8601143Sep 27, 2011Dec 3, 2013Cisco Technology, Inc.Automated configuration of network device portsUS8604910Dec 13, 2005Dec 10, 2013Cisco Technology, Inc.Using syslog and SNMP for scalable monitoring of networked devicesUS8631100Jul 20, 2010Jan 14, 2014Juniper Networks, Inc.Automatic assignment of hardware addresses within computer networksUS8698603 *Feb 3, 2006Apr 15, 2014Cisco Technology, Inc.Methods and systems for automatic device provisioning in an RFID network using IP multicastUS8700778Sep 2, 2010Apr 15, 2014Cisco Technology, Inc.Provisioning and redundancy for RFID middleware serversUS8745176 *Oct 10, 2008Jun 3, 2014Samsung Electronics Co., Ltd.Method and device to set device configurationsUS8782211Dec 21, 2010Jul 15, 2014Juniper Networks, Inc.Dynamically scheduling tasks to manage system loadUS8851383 *May 2, 2011Oct 7, 2014Hand Held Products, Inc.Data collection system having reconfigurable data collection terminalUS9007181 *Jan 8, 2010Apr 14, 2015Tyco Fire & Security GmbhMethod and system for discovery and transparent status reporting for sensor networksUS9021100Aug 22, 2012Apr 28, 2015Juniper Networks, Inc.Tunneling DHCP options in authentication messagesUS9055050 *Jun 27, 2012Jun 9, 2015Facebook, Inc.User authentication of applications on third-party devices via user devicesUS9064164Sep 30, 2013Jun 23, 2015Cisco Technology, Inc.Methods and systems for automatic device provisioning in an RFID network using IP multicastUS9111157 *May 7, 2013Aug 18, 2015Insight Holding Group, Inc.System and method for tracking shopping behaviorUS20050264420 *Apr 11, 2005Dec 1, 2005Cisco Technology, Inc. A Corporation Of CaliforniaAutomated configuration of network device portsUS20060033606 *Jul 13, 2004Feb 16, 2006Cisco Technology, Inc. A Corporation Of CaliforniaMethods and apparatus for determining the status of a deviceUS20060091999 *Dec 13, 2005May 4, 2006Cisco Technology, Inc., A Corporation Of CaliforniaUsing syslog and SNMP for scalable monitoring of networked devicesUS20060266832 *Jul 31, 2006Nov 30, 2006Cisco Technology, Inc.Virtual readers for scalable RFID infrastructuresUS20070109100 *Feb 3, 2006May 17, 2007Cisco Technology, Inc.Methods and systems for automatic device provisioning in an RFID network using IP multicastUS20080197980 *Apr 11, 2008Aug 21, 2008Cisco Technology, Inc.Methods and devices for providing scalable RFID networksUS20080300951 *Jun 4, 2007Dec 4, 2008Cisco Technology, Inc.Dynamic staffing using population countUS20090100155 *Oct 10, 2008Apr 16, 2009Jong-Nam LeeMethod and device to set device configurationsUS20100191813 *Feb 6, 2009Jul 29, 2010Juniper Networks, Inc.Automatically releasing resources reserved for subscriber devices within a broadband access networkUS20100191839 *Mar 25, 2010Jul 29, 2010Juniper Networks, Inc.Synchronizing resource bindings within computer networkUS20110004781 *Sep 2, 2010Jan 6, 2011Cisco Technology, Inc.Provisioning and redundancy for rfid middleware serversUS20110063082 *Sep 2, 2010Mar 17, 2011Toshiba Tec Kabushiki KaishaWireless tag reader and wireless tag reading methodUS20110169612 *Jan 8, 2010Jul 14, 2011Sensormatic Electronics, LLCMethod and system for discovery and transparent status reporting for sensor networksUS20110238793 *Sep 29, 2011Juniper Networks, Inc.Managing distributed address pools within network devicesUS20120194320 *Aug 2, 2012Yeakley Daniel DData collection system having reconfigurable data collection terminalUS20130023280 *Jul 20, 2011Jan 24, 2013Qualcomm IncorporatedWireless Device Secure TrackingUS20130293355 *May 7, 2013Nov 7, 2013James ChristopherSystem and method for tracking shopping behaviorUS20140007195 *Jun 27, 2012Jan 2, 2014Vikas GuptaUser Authentication of Applications on Third-Party Devices Via User DevicesUS20150029002 *Sep 29, 2014Jan 29, 2015Hand Held Products, Inc.Data collection system having reconfigurable data collection terminal* Cited by examinerClassifications U.S. Classification235/451, 340/10.41, 340/8.1, 340/572.1International ClassificationH04L29/08, H04L12/56, H04L12/24, H04L29/12, G06K7/08, G08B13/14, G08B13/24Cooperative ClassificationH04L67/1002, H04L67/1021, H04L41/0843, H04L41/0806, H04L41/0883, G08B13/2402, H04L29/12066, H04L61/6063, H04L29/12216, H04L29/12801, H04L29/12924, H04W28/08, H04L61/6004, H04W8/26, H04L41/12, H04W4/00, H04L61/1511, H04L61/2015Legal EventsDateCodeEventDescriptionMay 12, 2005ASAssignmentOwner name: CISCO TECHNOLOGY, INC., CALIFORNIAFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:DROMS, RALPH;VOGEL JR., GARY DENNIS;SAVILLE, ROLAND;REEL/FRAME:016573/0034;SIGNING DATES FROM 20050511 TO 20050512Dec 28, 2010CCCertificate of correctionJul 19, 2013FPAYFee paymentYear of fee payment: 4RotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services