WO2004100098A1

WO2004100098A1 - Apparatus for and method of writing an electronic product identification code (epic)

Info

Publication number: WO2004100098A1
Application number: PCT/US2004/013809
Authority: WO
Inventors: Richard J. Campero; Martin D. Weel
Original assignee: Meadwestvaco Corporation
Priority date: 2003-05-01
Filing date: 2004-04-30
Publication date: 2004-11-18
Also published as: EP1668612A1; EP1668612A4

Abstract

An apparatus (100) and method are provided for writing identifying information to RFID tags (60) and using the item information (70) to perform various inventory management processes. In accordance with a preferred embodiment of the invention, the writing of item information (70) may include writing to the RFID tags (60) an electronic product identification code (EPIC) that may contain item specific information such as manufacturer and stock number, and also a serial number unique for that particular combination of manufacturer and stock number.

Description

APPARATUS FOR AND METHOD OF WRITING AN ELECTRONIC PRODUCT IDENTIFICATION CODE (EPIC)

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This patent application claims the benefit of U.S. provisional patent application number 60/466,760, filed May 1, 2003. This application is a continuation-in-part of pending U.S. Application No. 10/338,892, filed January 9, 2003, which claims the benefit of U.S. Provisional Application No. 60/346,388, filed January 9, 2002, and U.S. Provisional Application No. 60/350,023, filed January 23, 2002. This application is also a continuation-in-part of pending U.S. Application No. 10/348,941, filed January 23, 2003, which claims the benefit of U.S. Provisional Application No. 60/350,023, filed January 23, 2002, and is itself a continuation-in-part of pending U.S. Application No. 10/338,892, filed January 9, 2003. All of the foregoing applications are incorporated herein by reference in their entireties.

BACKGROUND

[0002] Inventory management is becoming increasingly important in today's growing economy. Although this growth provides consumers with more choices for selecting various goods and services, businesses (e.g., retailers, wholesalers, etc.) are tasked with managing this growing inventory.

[0003] To manage growing product inventories, businesses have implemented perpetual type inventory management systems. Personal type inventory management systems use Point Of Sale (POS) data on products sold, invoicing data, and historical data on inventory audits or cycle counts (e.g., periodic inventory counts of products) to monitor the inventory inside a retail store. POS data generally refers to data generated at a checkout system (e.g., cash register). Based on the inventory level within the retail stores, products may be reordered from a manufacturer. Alternatively, the manufacturer and retailer may have an agreement that directs the manufacturer to preemptively deliver products according to the terms of the agreement.

[0004] Although perpetual inventory management systems alleviate some of the burden in managing large inventories, they may also introduce error into management systems (e.g., errors in cycle counts, POS scanning data, redundant re-ordering, misdirected shipments, and/or unusual sales velocity (i.e., the sale of products that take place either too fast or too slow)). Perpetual inventory management systems introduce other artifacts such as inventory shrinkage (i.e., reduction of inventory due to non-sale circumstances). For example, shrinkage may occur at any point in a supply chain, stemming from invoice errors, vendor fraud, misdirected shipments, retail employee theft and customer theft. If inventory is computed as described above (i.e., using perpetual inventory management techniques), shrinkage rates (amounting to several percent of sales) can cause divergence of perpetual and physical inventory.

[0005] To address the shortcomings of conventional inventory management systems, businesses have begun to incorporate wireless identification devices to assist in managing the inventory of products. This advancement contemplates attaching Radio Frequency Identification (RFID) tags to products during manufacture or when the products are stored in a warehouse.

Each RFID tag includes an Integrated Circuit (IC) that enables the tag to have a unique identification number. Therefore, when a product is taken from a warehouse and placed on a retail shelf, for example, the products may be scanned to give a comprehensive inventory. Further, RFID tag technologies can be used to provide distributed inventory management between a manufacturer and a retailer. For example, a manufacturer may be alerted through the Internet each time a product is sold at a retailer using the information stored in the product's RFID tag. The manufacturer may then use this information to forecast replenishment schedules with the retailer to prevent an out-of-stock situation.

SUMMARY

[0006] An apparatus and method are provided for writing identifying information to RFID tags and using the item information to perform various inventory management processes. In accordance with a preferred embodiment of the invention, the writing of item information may include writing an electronic product identification code (EPIC) to the RFID tags that may contain item specific information such as manufacturer and stock number, and also a serial number unique for that particular combination of manufacturer and stock number.

BRIEF DESCRIPTION OF THE DRAWINGS

[0007] FIG. 1 is a block diagram for a Tag Burner system as an exemplary embodiment of the invention;

[0008] FIG. 2 illustrates an exemplary implementation of a Tag Burner in accordance with an embodiment of the invention; and

[0009] FIG. 3 is a flowchart illustrating an exemplary process in accordance with an embodiment of the invention. DETAILED DESCRIPTION

[0010] Preferred embodiments and applications of the invention will now be described. Other embodiments may be realized and changes may be made to the disclosed embodiments without departing from the spirit or scope of the invention. Although the preferred embodiments disclosed herein have been particularly described as applied to the writing to tags in the field of RFID systems, it should be readily apparent that the invention may be embodied in any technology having the same or similar problems.

[0011] Various embodiments of the invention enable an intelligent inventory management process to monitor and collect information associated with an inventory of items. An "item," as the term is used herein, may include any type of product (or other tangible object) that is manufactured, developed, grown by an agricultural business, or otherwise provided or utilized by a manufacturer, supplier, retailer, individual, or other entity.

[0012] The information that is collected may be used to perform various inventory management processes that enable a user to control the inventory of items, monitor amounts of inventory, facilitate and identify recalled or defective items included in the inventory, manage the misplacement of items, and receive alert messages associated with a variety of inventory conditions, such as security conditions, out of stock conditions, etc.

[0013] FIG. 1 is a block diagram of an exemplary embodiment of the invention. As shown, Tag Burner 100 may include a main controller for controlling the overall operations of Tag Burner 100. The main controller may include one or more central processing units (CPUs) or other calculating or processing devices, symbolically represented by controller 110. Controller 110 may be used to provide processing of input/output data between Tag Burner 100 and network 160, and among the different modules within Tag Burner 100. Controller 110 typically executes one or more computer programs stored in the one or more memory devices (or recording mediums in the form of articles of manufacture) symbolically represented as local database 115, and may be used to control the different modules comprising Tag Burner 100.

[0014] In accordance with a preferred embodiment, the Tag Burner includes a bar code scanner 120 for reading a bar code (e.g., one, two multidimensional bar codes)(not shown in FIG. 1) associated with an item. Any type of information carrier that may be scanned, read or otherwise interpreted may be used. In another embodiment, means for inputting (e.g., implementations of user interface device 130 such as a touchscreen, mobile device, PDA, wireless keyboard, voice activated input device, stylus, etc.) can be used to provide such information. Such user interface devices 130, as well as the bar code scanner 120, may optionally be integral to the structure containing the reader antenna 150 (e.g., as indicator lights), or they may be separate from the structure containing the antenna (e.g., a computer monitor).

[0015] The exemplary Tag Burner 100 may further include an RFID reader 140. The reader 140 is shown connected to a reader antenna 150. Antenna

150 is preferably used to communicate by radio frequency waves 50 with RFID tag 60, shown attached to item 70. The antenna 150 may include tuning circuitry such as that described in US Patent Application No. 10/338,892, which is incorporated herein by reference in its entirety. The antenna 150 may be controlled by controller 110, for example, to switch between antenna loops, if more than one loop is provided as part of antenna 150. Antenna 150 may also ■serve as a writing device controlled by controller 110 to write data (e.g., EPIC's) to RFID tag 60, as will be described in more detail below.

[0016] Tag Burner 100 may be connected directly or indirectly (e.g., through network 160, as shown in FIG. 1) to a licensing and verification service (LANS) module, which is symbolically represented as LANS 170 coupled to main database 180. Network 160 may represent any type of communication configuration that allows Tag Burner 100 and LAVS 170 to exchange information. (For example, network 160 may be a Local Area Network (LAN), a Wide Area Network (WAN), Bluetooth™, and/or a combination of networks, such as the Internet.) Network 160 may also include the infrastructure that allows Tag Burner 100 and LAVS 170 to exchange information using wireless based communications .

[0017] Local database 115 and main database 180, in each instance, may be one or more storage device systems that store information used by the

Tag Burner 100 and / or LAVS 170 to perform the Tag Burner features consistent with the invention. In the sense used here, "database" may mean more than one data file or table comprising a local database 115 and/or a main database 180.

Furthermore there may be multiple instances of the main database 180, or parts of the main database 180 may be located in separate (local and/or remote) locations. In preferred commercial implementations, such databases may be controlled by a database server (not shown), such as an SQL database server. In another preferred embodiment, a Java DataBase Connectivity (JDBC) driver for the SQL server may also be used to access the SQL server database. Local database 115 may be embodied within tag burner 100, or be external to tag burner 100, for example on a server (not shown). Furthermore, local database may be shared with more than one tag burner 100. [0018] In accordance with a preferred embodiment, local database 115 and/or main database 180 may be used to store item information associated with each identifier included in the RFID tags 60. The stored information may include identification information regarding an item such as Stock Keeping Unit (SKU) data. The SKU information may include item type, manufacturer and origin, size, color, style, as well as a wide variety of other types of information that are understood by those skilled in the art. Preferably, the item information stored may be selected from:

1) A Uniform Product Code (UPC) and/or an Electronic Product

Identification Code (EPIC). It should be understood that items made

by a certain manufacturer in a certain size, color, etc., may have all the

same UPC but each may have a unique EPIC.

2) A current price of the item.

3) An indicator of a seasonality of the item. A seasonality indicator may

represent a relationship between an item and a period of time

associated with different events or seasons, such as holidays, a time

frame surrounding a certain date of a special event (e.g., the Super

Bowl), etc. For example, a soap product may have a seasonality

indicator representing no seasonal characteristics, such as "no season,"

wreaths may have a "Christmas" indicator, charcoal may have a

"summer" indicator, etc. Further, promotional items (e.g., those items

that are being specially marketed by a manufacturer or retailer) may have a seasonality indicator associated with a time frame, such as "July

2003," etc. The seasonality indicators may be used to determine when

to remove or restock certain items in inventory.

4) A shelf life of the item. A shelf life may be a period of time that an item

may be allowed to be included in inventory. For example, perishable

products, such as milk, may have a limited period of time that they

may be presented on a shelf for sale to a customer. Non-perishable

products may also have a limited period of time to be present in

inventory based on one or more factors, such as previous sales of items

of a similar type, limited promotional time frames, etc.

[0019] Additionally, for an item collection of a certain type (e.g., an individual box of any type of item), the stored item information may preferably be selected from:

1) The EPIC of the item.

2) The UPC of the item to relate back to the SKU information described

above.

3) Other types of information not directly known from the SKU (e.g.,

color, style, size).

4) A serial number associated with the item (if other than the EPIC).

5) A cost of the item to a business entity associated with its use, such as a

retailer. 6) A date the item was first placed in a particular location or locations.

7) An expiration date of the item (if any).

8) Item location information representing a current physical location of

the item in (or if sold, the last known location of the item).

9) A price an item sold was sold (if already sold).

10) A date the item was sold (if already sold).

11) A preferred customer number of a purchaser (if already sold)

representing a unique number assigned to a user that purchases or

may purchase items.

12) A unique serial number associated with the RFID tag 60, for example,

an identification number written to the RFID tag 60 by its

manufacturer. This number may serve for example for tag quality

control or other uses, and may be read but not rewritten.

[0020] One skilled in the art will appreciate that the above listed tables are exemplary and not intended to be limiting. Database 180 may include more or fewer tables that are configured to store various types of information used by LAVS 170 and/or Tag Burner 100. Some or all of the information in main database 180 may also be stored in local database 115.

[0021] An illustration of part of an exemplary Tag Burner implementation in accordance with an embodiment of the invention is shown in

FIG. 2. This illustration shows the bar code scanner 120, antenna 150, and visual indicators representative of user interface devices 130. Also shown is an exemplary item 70 having an RFID tag 60 and bar code 65. An optional support arm 121 may be used to hold the bar code scanner 120 in a position for readily scanning the bar code 65. Although FIG. 2 does not show the connections to the controller 120 or reader 140, it should be readily apparent to those of ordinary skill in the art that any necessary wired/wireless connections may be made in implementing this embodiment. Tag Burner 100 may access its local database 110, or the main database 180 through the LAVS 170, to obtain identification numbers, such as the next available EPIC for a given bar code 65 (i.e., UPC). Tag Burner 100 may also obtain additional information about the product, either based on the bar code 65 or based on the EPIC, if the tag 60 is already programmed.

[0022] In accordance with a preferred embodiment of the invention, a process may be performed (e.g., using Tag Burner 100) for writing EPICs to particular RFID tags to provide a unique EPIC to each particular RFID tag 60. FIG. 3, for example, illustrates an exemplary implementation of such a process using the Tag Burner 100 of FIG. 1. In step 300, the controller 110 may obtain a list of SKU's related to the items 70 that are expected to be processed. Such a list of SKU's is optional, and if obtained, may preferably be stored in local database 115. The list may be obtained, for example, from a manufacturer of the items 70, or may be obtained through various communications or storage means including Internet, LAN, diskette, or any other such means known to those skilled in the art.

[0023] In accordance with preferred embodiments of the step 310, a reading device (e.g., reader 140 and reader antenna 150) determines whether there is an RFID tag 60 within range of the antenna (step 310). If no RFID tag 60 is detected, the reading device continues to attempt to read a tag until one is detected. If an RFID tag 60 is detected, then the reading device determines if the tag has been written with an EPIC (step 315). If the tag has been written with an EPIC, optional step 317 can be used to avoid rewriting EPICs to an RFID tag 60 that already has been written. The indication may include a visual indicator (e.g., color, text, etc.), an audible indicator, or any other perceptible notification. If the indication is visible, it may be provided by User interface devices 130 such as lights or a monitor that may optionally provide additional information about EPICs that have already been written to an RFID tag 60.

[0024] If an RFID tag 60 has been detected, then if it is not yet written with an EPIC code, or if the user decides against the option in step 317, then in step 320 the SKU or other identifying information about the item 70 is input to the system. This input may be by any known means (e.g., use of the bar code scanner 120 reading the bar code 65, input of the numeric representation of bar code 65 through keyboard or voice recognition mechanism in user interface device 130, visible or audible indicators or sensors, a computer monitor, a computer mouse, touchscreen, mobile device, PDA, wireless keyboard, voice activated input device, or stylus). In the case of an item 70 not having an attached bar code 65, the user may input an SKU by scanning the appropriate bar code from a list, or by entering such a bar code by any alternative means such as those already described.

[0025] The system having obtained the SKU, the system (in step 325) may optionally display information about item 70 (e.g., the title of an optical disk product) that may be useful to the user.

[0026] In step 330, the system determines whether the local database 115 contains an EPIC for the current SKU. An EPIC in this sense may be taken to mean a unique EPIC available for the current SKU. If such an EPIC is not available in local database 115, then the system may obtain one or more suitable EPICs from a Licensing and Verification Service (LAVS) (e.g., LAVS 170 shown in FIG. 1). The LAVS 170, for example, may be a system that ensures that EPICs being written are always unique numbers. The LAVS 170 may preferably access a secure centralized database or databases (e.g., database 180) using a network 160 such as the Internet or any other communication means.

[0027] In step 340, the EPIC is written to RFID tag 60. In step 350, the RFID tag 60 is read to verify that the EPIC has been written properly. If not, the write operation in step 340 may be repeated one or more times, until the write operation succeeds. If the write operation does not succeed, the user may be given an optional warning message.

[0028] In step 360, the local database may be updated, for example, to indicate a successful writing of the EPIC to item 70, which reduces the number of available EPICs in the local database. Optionally the LAVS 170 may also be updated.

[0029] The process continues by repeating the cycle, starting with step 300, wherein a list of SKU's may be obtained, as discussed above. Optionally, step 300 may only be repeated periodically (e.g., once per shift, once per day, once per week, whenever new items 70 having new SKUs are introduced into the system, etc.).

[0030] When EPICs are obtained from the LAVS 170, and stored in the local database 115, the EPICs may be obtained one at time for each UPC, or several at a time for each UPC, for example, hundreds or thousands in one request. When more than one EPIC is obtained for a given UPC, the EPICs may be contiguous or non-contiguous. They may be obtained as individual EPICs, or as blocks of EPICs. They may be obtained as a range of EPICs (e.g., defined by the first and last EPICs in the range, defined by the first EPIC in the range and the count of EPICs in the range, etc.). Likewise the EPICs may be stored in the main database 180 and the local database 115 as individual EPICs, or as blocks of EPICs, or as a range of EPICs. Obtaining EPICs as a block, or particularly as a range, may decrease the transmission time. Storing EPICs as blocks, or particularly as ranges, may decrease the database memory requirements.

[0031] EPICs may be obtained as needed, that is, when an item 70 bearing a particular UPC is ready to have its RFID tag 60 written by the tag burner 100. Alternately, it may be more efficient to obtain one or more EPICs in advance. Examples of methods for obtaining EPICs in advance for a given UPC include obtaining a group of EPICs whenever the count of available EPICs falls below a preset number, or falls to zero. Thus there will usually be at least one EPIC for a given UPC available in the local database. The number of EPICs needed for each SKU may be known in advance, for example from forecasts or actual records of sales, demand, production, etc. of the number of items 70 with a given SKU that will be processed by one or more tag burners within a given time, for example during the next 24 hours. This number of EPICs may then be requested in advance from the LAVS 170. Such forecast knowledge of the required number of EPICs, since they may be known in advance, may permit the tag burner 100, or a server with access to the local database 115, to request the EPICs from LAVS 170 during idle times such as night time hours when network traffic is low, or during meal or break times if tag burner 100 is manually operated, or during other times when the resources of a network or tag burner 100 are less utilized.

[0032] In order to reduce the number of times that EPICs are requested from the LAVS 170, it may be advantageous to request somewhat more numbers than may be required. However, this may result in the local database 115 eventually holding some non-used EPICs. It may become apparent that the non-used EPICs in the local database 115 will not be used by tag burner 100, at which time the non-used EPICs in the local database 115 may be returned to the LAVS 170 and then to the main database 180. The fact that non-used EPICs in the local database 115 are not likely to be used may be recognized by several factors, for example, knowledge that no requests for these non-used EPICs have been received within a set period of time, indicating no demand for the associated product. Another factor would be a promotional product no longer being promoted, or a new release product after several weeks, wherein past experience indicates that the number of non-used EPICs in the local database 115 are no longer likely to be needed.

[0033] Another method of handling non-used EPICs in the local database 115 would be to assign an "expiration date" to each EPIC or group of EPICs, so that after the expiration date, the unused EPICs may be automatically returned to the LAVS 170 and main database 180. Returning such non-used EPICs to the LAVS 170 and main database 180 may allow more efficient use of the EPICs, by reducing the number of EPICs that would otherwise not be used. Returning unused EPICs would also allow for efficient use of memory by local database 115. [0034] The LAVS 170, besides providing the "licensing" function of ensuring that all EPICs are unique, may also provide a "verification" function for example to verify that an RFID tag 60 containing an EPIC is authentic. One means of verification would be for the tag burner 100, upon writing an EPIC into RFID tag 60, to read back a tag serial number that the tag manufacturer had prewritten into the tag. Such a serial number cannot be rewritten after manufacture. This serial number may then be transmitted back to the LAVS 170 for storing in the main database 180 along with the EPIC that was written to the tag. Thereafter, any process (the tag burner, or any other RFID reader process) upon reading the EPIC, may also read the tag serial number, and by communication with the LAVS 170, determine whether the EPIC is authentic.

[0035] The following are examples of commercial implementations of preferred embodiments of the invention.

EXAMPLES

[0036] In an exemplary commercial implementation of a preferred embodiment of the invention, the Tag Burner 100 may be implemented using a Windows^® executable process (such as a computer program) that may use .NET serial implementations to communicate to reader 140. The Tag Burner 100 may store, for instance, in a file location or in local database 110, the number for the last EPIC written to an RFID tag for a given manufacturer and its SKU information (e.g., item type information). Further, the Tag Burner process may store a range of serial numbers, SKU information, and manufacturer ID's for an EPIC and write this EPIC information to the memory of one or more RFID tags 60. The Tag Burner may also write to RFID tags 60 based on a standard, such as the Philips SLRM900 specification that defines communication between the reader 140/antenna 150 and the tag 60 (sometimes called the "air interface"), depending on the type of RFID tags 60 being used. RS-232 or other interface communication protocols may be used between the controller 110 and the reader 140.

[0037] In accordance with exemplary implementation, an environment (e.g., retail store, etc.) uses a system of RFID-enabled structures, such as shelf units, to keep track of an inventory of items. In implementing such an embodiment, the Tag Burner 100 may incorporate antenna 150 (shown in FIG. 1) as a form factor antenna. Alternately, the antenna or antennas 150 may be contained in one or more RFID enabled shelves (not shown) that include communication capabilities with controller 110 and reader 140, such as described in U.S. Application No. 10/338,892, which is incorporated herein by reference in its entirety. Accordingly, each shelf may, at least temporarily or periodically, communicate exclusively with the Tag Burner.

[0038] As an example, an item or a group of items of a certain type are physically placed on a shelf by a user. The placed items may then be scanned with a bar code scanner to determine its corresponding UPC number. The Tag Burner 100 then assigns EPICs to each item in the group by incorporating the information derived from the UPC number.

[0039] In accordance with a preferred implementation, differences between a common UPC and an EPIC may be provided, as shown in Table I. A UPC, for example, may consist of decimal (i.e., base ten) data including manufacturer number, object number, and a check digit, totaling 12 digits. An EPIC may include binary data that may include a header, manufacturer number, object number, and electronic serial number. In both the UPC and EPIC, the manufacturer number may be assigned by a governing body, such as price code standards governing body. An object class (including the object number) may be assigned by a manufacturer. In the case of an EPIC, the serial number may also be assigned by the manufacturer.

Table I. Differences Between UPCs and EPICs

[0040] In situations where a manufacturer or manufacturers have not been assigned EPIC manufacturer codes, the Tag Burner 100 may use arbitrary number assignments until the EPIC manufacturer codes are assigned. The Tag Burner 100 may also be used in an arbitrary pseudo-EPIC field arrangement for use in initial inventory operations, such as trial inventory management processes that incorporate the current UPC field values or arbitrary values as the manufacturer's codes. Alternatively, the existing UPC manufacturer codes, which fit directly into the larger EPIC manufacturer field, may be used. Also, the existing UPC object class would fit into the larger EPIC object field.

[0041] If a standard EPIC field arrangement has been implemented, the Tag Burner may be used to ensure items are properly tagged. Also, if a standard EPIC field arrangement is promulgated, the Tag Burner 100 may be used by retailers, distribution centers or manufacturers, possibly for limited product lines.

[0042] If the pseudo-EPIC field arrangement is implemented, EPIC codes may be assigned by defining a determined number of fields (e.g., three) for the pseudo-EPIC. For example, the pseudo-EPIC may be arranged with an 8-bit header (1111,1111) that corresponds to the type header in the EPIC, a 52-bit UPC field that is divided into 13 subfields of 4 bits each, and a 36-bit serial number field, such as a sequential number, 0 to 68,719,476,735). The size of the data segments in the EPIC may vary without departing from the scope of the invention.

[0043] The UPC number is made up of up to 13 digits, using the binary representation of each digit, one nibble per UPC digit. That is, 0 is 0000, 1 is 0001, 2 is 0010, ... and 9 is 1001. Individual packages of a given item may be assigned unique serial numbers until more than 68.7 billion packages are encountered. Alternatively, there may be a difference in how the UPC number and the serial number are treated by the Tag Burner when converting to a binary representation. In the case of the UPC number, each UPC digit (up to 13 digits) is assigned a nibble in the EPIC. A binary conversion may be performed by Tag Burner digit by digit, keeping particular decimal digits in correspondence with particular EPIC nibbles. In the case of the EPIC serial number, however, a straight conversion may be performed from the decimal serial number to the binary serial number, which is recorded in the 36-bit EPIC field.

[0044] An exemplary 96-bit pseudo-EPIC code that has been filled with an exemplary bar code for a type of item (e.g., a 10-fl oz bottle of a multi- symptom cold/flu relief medicine) may serve as an example. The bar code may be 23900,00296 (or 000,23900,00296 in 13-digit form). A serial number of 34782 may have been assigned to make the package for this item type unique. In binary representation, 34782 is 0100,0011,1110,1111. Table II shows the corresponding EPIC and UPC data associated with this exemplary item type.

Table II. - Exemplary UPC and EPIC codes for Exemplary Item Type

[0045] To facilitate assignment of the appropriate pseudo-EPIC to tagged items, the Tag Burner 100 may record the 12- or 13-digit UPC number electronically at the time when the serial number is assigned and the RFID tag 60 is applied to the item 70 or the package of the item 70.

[0046] The above described RFID tagging process may be performed under the Tag Burner process shown in the flowchart of FIG. 3. As shown, the Tag Burner process may obtain a list of SKUs (item types) to be tagged (step 300-310). This list may include the UPC number for each item type and a character string identifying the item, and may be stored in an SKU table that may be filled by any known type of bar code scanning software and/or hardware. In an exemplary implementation, the SKU table may include three fields, an UPC number field, a manufacturer name field, and a character string to include general description information, such as size, flavor, etc.

[0047] At the time when an RFID tag 60 is to be assigned to an item 315, the Tag Burner process receives the SKU of the item in step 320. Alternately, the Tag Burner process may run a Tag Burner task algorithm to obtain the SKU. The algorithm would run to access an SKU table 320 (which may be stored in database 180 and/or database 120) and locate a corresponding UPC for each SKU included in the list obtained in step 310 (or step 320). For example, the Tag Burner task algorithm may generate a query to search the SKU table according to a manufacturer name or an item name.

[0048] Once a UPC is located for a corresponding SKU, the Tag Burner task algorithm then provides this information back to the Tag Burner process. Once received, the Tag Burner process may use the UPC to write the entire pseudo-EPIC to the RFID tag on each package of the item type by, for example, using a write-to-tag command that is executed by the RFID reader (step 330). This step assigns the unique serial numbers to each tag. Further, the Tag Burner process may log the pseudo-EPIC into a table during this procedure, such as a table stored in database 180 or database 120 (step 340).

[0049] An RFID tag 60 may contain both the serial number that is assigned as the unique RFID tag number, as well as the pseudo-EPIC that is encoded as extra data. Although the pseudo-EPIC includes information that identifies item 70, the serial number may be read faster by reader software/hardware than the pseudo-EPIC. For example, an anti-collision select command provided by certain bar code scanners, such as the Philips reader, may automatically return the RFID tag serial numbers. In instances where the type of items located on a particular shelf change very little from one RFID tag read operation to another, the read cycle for obtaining the pseudo-EPIC may be improved by storing the EPIC information and corresponding serial number information in a local cache memory device (not shown). Accordingly, the reader may issue an anti-collision select command when attempting to read an RFID tag 60 and initially receive the RFID tag serial number. The reader may then determine whether the tag serial number is located in the local cache. If it is, then the reader may retrieve the corresponding EPIC from the cache. If the tag is not stored in the cache, then the reader may read the tag data blocks to obtain the pseudo EPIC. The RFID tag serial number and EPIC may then be added to the cache for a subsequent read cycle. A purge process may be performed to purge the tag information contained within the cache on a periodic basis. This may provide similar data access performance as a relational type database containing the tag serial number and EPIC, with less data management delays.

[0050] Additionally, controller 110 may include other types of interfaces such as user interface devices 130 that interact with the Tag Burner process to allow a user to not only read and write EPIC data from/to the RFID tags 60, but also to monitor the status of such operations. For example, user interface devices 130 may include a computer monitor interface that presents to a user a results window that includes a list of all items that were recently processed by the Tag Burner 100. The results window may include information that indicates whether an EPIC write operation was successfully performed. Various interactive display messages may be provided to the user based on the results of any EPIC writes. For example, the result window may present one or more error messages indicating a reason why an EPIC write was not successful and instructions on how to possibly correct the problem. Also, user interface devices 130 may include a bad tag finder that enables a user to request information on any malfunctioning RFID tags 60. The bad tag finder may present to the user information identifying the ID of any bad tags 60, and the associated item 70 associated with the tag 60.

[0051] While preferred embodiments of the invention have been described and illustrated, it should be apparent that many modifications to the embodiments and implementations of the invention can be made without departing from the spirit or scope of the invention. For example, although embodiments and implementations of the invention have been specifically illustrated herein as reading and writing RFID tags (e.g., tag 60, FIG. 1) placed on an item (e.g., item 70), the invention may easily be deployed or embodied in any form of (RF- or non-RF-based) tag, and may also include the reading and writing of tags that have not yet been placed on a given item at the time of writing. Although only a single Tag Burner 100 has been illustrated, it should be apparent that there may be multiple Tag Burners 100, and when implemented, connected (directly or indirectly) with one or more LAVS 170. Preferably, the multiple LAVS 170 coordinate with each other to avoid duplication of information (e.g., serial numbers) during the licensing and verification process (described in greater detail below). Various embodiments of the Tag Burner may include use by a retailer or supplier, a manufacturer (e.g., "source-tagging," where the RFID tags may be applied to items and the EPICs written to the tags by a manufacturer), or by individuals for commercial or non-commercial use.

[0052] To the extent the illustrated embodiments have not specified the type of communication medium (or protocol) used to connect the various modules (e.g., shown in FIG. 1), it should be apparent that any known wired/wireless technology may be used to implement the various embodiments of the invention (e.g., PCI bus, firewire, USB, Internet, intranets, private bulletin boards, individual local or wide area networks, proprietary chat rooms, ICQ, IRC channels, instant messaging systems, WAP, bluetooth, etc.) using real-time or non-real-time systems alone or in combination.

[0053] In accordance with a preferred embodiment, one or more of the same or different user interfaces (e.g., user interface device 130 (FIG. 1)) are provided as part of (or in conjunction with) the illustrated systems to permit one or more users to interact with the systems. Individual ones of a plurality of devices (e.g., network/stand-alone computers, personal digital assistants (PDAs), WebTV (or other Internet-only) terminals, set-top boxes, cellular/PCS phones, screenphones, pagers, kiosks, or other known (wired or wireless) communication devices, etc.) may similarly be used to execute one or more computer programs (e.g., universal Internet browser programs, dedicated interface programs, etc.) to allow users to interface with the systems in the manner described.

[0054] The modules described herein, particularly those illustrated or inherent in, or apparent from the instant disclosure, may be one or more hardware, software, or hybrid components residing in (or distributed among) one or more local and/or remote computer or other processing systems. Although the modules may be shown or described herein as physically separated components (e.g., controller 110, local database 115, bar code scanner 120, user interface 130, reader 140, etc.), it should be readily apparent that the modules may be omitted, combined or further separated into a variety of different components, sharing different resources (including processing units, memory, clock devices, software routines, etc.) as required for the particular implementation of the embodiments disclosed (or apparent from the teachings herein). Indeed, even a single general purpose computer (or other processor- controlled device) executing a program stored on an article of manufacture (e.g., recording medium such as a CD-ROM, DVD-ROM, memory cartridge, etc.) to produce the functionality referred to herein may be utilized to implement the illustrated embodiments. User interface devices may be any device used to input and/or output information. The user interface device may be implemented as a graphical user interface (GUI) containing a display or the like, or may be a link to other user input/output devices known in the art.

[0055] In addition, database, storage, and other memory units described herein may be any one or more of the known storage devices (e.g., Random Access Memory (RAM), Read Only Memory (ROM), hard disk drive (HDD), floppy drive, zip drive, CD-ROM, DVD-ROM, bubble memory, redundant array of independent disks (RAID), storage accessible network (SAN), network accessible storage (NAS), etc.), and may also be one or more memory devices embedded within a controller or CPU, or shared with one or more of the other components. These units may be disposed locally, remotely, distributed, or otherwise logically or physically configured to practice the invention. [0056] Moreover, the operational flow and method shown in (and described with respect to) FIG. 3 can be modified to include additional steps, to change the sequence of the individual steps as well as combining (or subdividing), simultaneously running, omitting, or otherwise modifying the individual steps shown and described in accordance with the invention. Numerous alternative methods may be employed to produce the outcomes described with respect to the preferred embodiments illustrated above or equivalent outcomes.

[0057] It is to be understood therefore that the invention is not limited to the particular embodiments disclosed (or apparent from the disclosure) herein, but only limited by the claims appended hereto.

Claims

CLAIMS[0058] What is claimed as new and desired to be protected by Letters Patent of the United States is:

1. A method of generating RFID product identification data associated with an item, the method comprising the steps of:

receiving RFID tag data;

receiving item identification data, wherein the item identification

data corresponds to the item;

appending a serial number to said item identification data; and

processing the item identification data and serial number to

generate RFID product identification data based on the received RFID tag

data.

2. The method of claim 1, wherein the item identification data comprises at least one manufacturer number and at least one Stock Keeping Unit (SKU) number.

3. The method of claim 1, wherein said step of appending a serial number to the item identification data comprises accessing a database containing a list of item identification data, and selecting a serial number that is not associated with any other item having the identification data.

4. The method of claim 3, wherein the serial number is associated with at least one manufacturer number and the at least one SKU number by at least one record in the database.

5. The method of claim 1, wherein the serial number comprises at least one manufacturer number and at least one SKU number.

6. The method of claim 1, wherein the serial number is written directly into the RFID tag.

7. The method of claim 1, wherein the serial number is associated with the RFID tag.

8. The method of claim 1, wherein the item identification data is read from a bar code.

9. The method of claim 4, the item identification data is read from a one-dimensional bar code.

10. The method of claim 4, the item identification data is read from a two-dimensional bar code.

11. An apparatus for writing an electronic product identification code (EPIC) on a product tag associated with a product, the apparatus comprising:

a controller receiving product identification information regarding

the product; a database storing product identification information and

corresponding EPIC information; and

a writing device for writing EPIC information to the product tag.

12. The apparatus for writing an electronic product identification code (EPIC) on a product tag as recited in claim 11, further comprising a reading device, coupled to said controller, for reading the product tag to verify the proper writing of EPIC information to the product tag.

13. The apparatus for writing an electronic product identification code (EPIC) on a product tag as recited in claim 12, wherein the writing device is a reader antenna, which is coupled to said reading device and said controller, wherein the reader antenna is in radio frequency (RF) communication with the product tag so as to permit said reading device to read the product tag and to permit writing of the EPIC information to the product tag.

14. The apparatus for writing an electronic product identification code (EPIC) on a product tag as recited in claim 11, further comprising a bar code scanner for reading a bar code, which is associated with the product and contains product information regarding the product, and for outputting the product information to said controller.

15. The apparatus for writing an electronic product identification code (EPIC) on a product tag as recited in claim 11, further comprising a user interface receiving as an input the product information regarding the product, and outputting the product information to said controller.

16. The apparatus for writing an electronic product identification code (EPIC) on a product tag as recited in claim 15, wherein said user interface includes visual indicators that indicate verification of the proper writing of EPIC information to the product tag.

17. An electronic product identification code (EPIC) writing system for use in writing an EPIC on an RFID tag associated with an item, wherein the item is associated with stock keeping unit (SKU) data, the writing system comprising:

a Tag Burner, wherein said Tag Burner receives the SKU data for the item, receives a unique EPIC, and writes a unique EPIC to the RFID tag; and

a licensing and verification service module, coupled to said Tag Burner, wherein said licensing and verification service module determine whether the EPIC written by said Tag Burner is unique.

18. The electronic product identification code (EPIC) writing system as recited in claim 17, wherein said Tag Burner determines whether a unique EPIC is available for each SKU it receives, and when none are available, receives at least one additional unique EPIC from said licensing and verification service module.

19. The electronic product identification code (EPIC) writing system as recited in claim 17, further comprising a network, wherein said licensing and verification service module is coupled to said Tag Burner through direct connection to said network.

20. The electronic product identification code (EPIC) writing system as recited in claim 17, further comprising a database for storing unique EPIC information.

21. The electronic product identification code (EPIC) writing system as recited in claim 20, wherein said database further stores item information including a uniform pricing code (UPC) associated with the item; color, style, size of the item; and a serial number associated with the item.

22. The electronic product identification code (EPIC) writing system as recited in claim 17, wherein when at least one unique EPIC having been obtained from said licensing and verification service module, and said at least one unique EPIC not having been written to an RFID tag within a certain time, the at least one unique EPIC is returned to said licensing and verification service module.

23. The electronic product identification code (EPIC) writing system as recited in claim 17, wherein said Tag Burner determines for at least one SKU whether there is a likelihood that the Tag Burner will process the SKU within a given time, and if so, prior to receiving the SKU for processing, said Tag Burner receives at least one additional unique EPIC from said licensing and verification service module.