WO2002101593A9 - System and method for managing historical information on an object on an electronic tag - Google Patents

Abstract

A distributed database system and associated methods maintain historical data regarding an entity, such as a person or an object, in a tag or other object in association with the entity. The data proper is maintained with the entity and the data rules used to interpret the data proper are maintained at a separate location. The data proper maintained with the entity is stored in a manner to reduce the amount of memory space required. The data proper maintained with the entity is effectively encrypted from parties that do not have access to the data rules. The data proper may be converted to a fixed form, such as a bar code label, and attached to the entity to permit historical information to be ascertained at a later time.

Description

SYSTEM AND METHOD FOR MANAGING HISTORICAL INFORMATION ON AN OBJECT ON AN ELECTRONIC TAG

Background of the Invention

Field of the Invention

[0002] The present invention relates in general to systems and methods for distributed data management, and in particular, to systems and methods for managing historical information regarding an object or a person.

Description of the Related Art

[0003] In recent years, the availability of databases and of computer networks has . given rise to a new technology called distributed databases. A distributed database is generally an integrated database which is built on top of a computer network rather than on a single computer. The data which constitute the database is stored at the different sites of the computer network, and the application programs which are run by the computers access data at different sites. Databases may involve different database management systems, running on different architectures, that distributes the execution of transactions.

[0004] Generally, a database contains both data (data proper) and data rules. Data proper is the raw information and the data rules are rules which make sense of the raw information. The data proper and data rules are usually kept in the same location. [0005] There are some disadvantages to distributed database system. For example, if a database server becomes inoperative, data cannot be accessed by the user computers. Moreover, even if the database server is operative, but a user computer loses access or connection to the database server, data cannot be accessed by the user computer. Generally, in distributed database systems, the data and the object referred to by the data remain physically separate and disconnected. The separation usually necessitates some means of identifying the referenced object and providing a key or cross-reference to the relevant data. This discontinuity between the data and the object referenced has several disadvantages. First, the a cross-reference or identifier must be maintained. Second, potential errors could arise when cross-reference identifiers are copied from the object and subsequently entered elsewhere to access the data. Third, the system is ineffective where there is limited access to the central or distributed database, or if unreliable channels of communication are used to receive information from remote sources.

Summary of the Invention

[0006] The present invention relates to systems and methods for managing historical information regarding an object or a person.

[0007] An aspect of the invention is a distributed database system for tracking historical information about an entity. The distributed database system comprises a processing system that includes data rules for processing received data, a data tag associated with the entity, the data tag storing historical data regarding the entity, the historical data stored on the data tag as variable field length encoded data in a plurality of data fields, and a communication system for transferring the variable field length encoded data between the processing system and the data tag, the processing system receiving the variable field length encoded data from the data tag and decoding the data to retrieve the historical data encoded on the data tag. The database system further comprises the processing system wherein the processing system revises the historical data and encodes the revised historical data into variable field length encoded data that is transferred to the data tag on the entity. The database system further comprises the data wherein the data in at least one of the plurality of data fields determines a field length of at least one other of the plurality of data fields. The database system further comprises an entity wherein the entity comprises an animal, and wherein the data tag is attached to the animal, the data tag comprising a storage device for storing the variable field length encoded data and a transceiver coupled to the storage device. The database system further comprises a communication system wherein the communication system includes a transceiver that communicates with the transceiver of the data tag to transfer historical data between the data tag and the processing system. The database system further comprises the entity wherein the entity is a product. The database system further comprises the product wherein the product is one of a plurality of products, each product in the plurality of products having a respective data tag so that each product can be distinguished by historical data stored on the respective data tag of the product.

[0008] Another aspect of the invention is a method of tracking historical information about an entity. The method of tracking historical information comprises storing the historical information as variable field length encoded data on a data tag associated with the entity, reading the variable field length encoded data and decoding the variable field length encoded data to reproduce the historical data, updating the historical data to include additional information about the entity, and storing the updated historical data as variable field length encoded data on the data tag associated with the entity. The method of tracking historical information further comprises converting the variable field length encoded data on the tag to a fixed form representation of the historical information for permanent association with at least a portion of the entity. The entity comprises a cow and a portion of the entity comprises a beef product of the cow. The fixed form representation of the historical information comprises a label having visible indicia. The visible indicia comprises a bar code. The visible indicia further comprises a two-dimensional bar code. [0009] For purposes of summarizing the invention, certain aspects, advantages and novel features of the invention have been described herein. Of course, it is to be understood that not necessarily all such aspects, advantages or features will be embodied in any particular embodiment of the invention.

Brief Description of the Drawings

[0010] The present invention is described in more detail below in connection with the attached drawings, which are meant to illustrate and not limit the invention, and in which:

[0011] Figure 1 illustrates a block diagram of a distributed database system, according to aspects of an embodiment of the invention;

[0012] Figure 2 illustrates a block diagram of a distributed database system, according to aspects of a particular embodiment of the invention; [0013] Figure 3 illustrates a block diagram of a physical division of data proper and data rules within a distributed database system, according to aspects of an embodiment of the invention;

[0014] Figure 4 illustrates a process diagram of data tag conversion during product processing, according to aspects of a particular embodiment of the invention;

[0015] Figure 5a illustrates an exemplary expanded view of data stored on a data tag, according to aspects of a particular embodiment of the invention; and

[0016] Figure 5b illustrates another exemplary expanded view of data stored on a data tag, according to aspects of a particular embodiment of the invention;

Detailed Description of the Preferred Embodiment

[0017] The present invention relates to systems and methods for managing historical information regarding an object or person with the historical information remaining with the object or person.

[0018] Figure 1 illustrates a block diagram of a distributed database system 100, according to aspects of an embodiment of the invention. The distributed database system 100 includes a field control device 110 and data tag 120. In one embodiment of the invention, the distributed database system 100 further comprises a data server 130. The data tag 120 is maintained in proximity of a tracked entity 140. In one embodiment of the invention, the data tag 120 is attached to the tracked entity 140. [0019] The field control device 110 comprises any device capable of operating a computer program and communicating data with other devices. In one embodiment of the invention, the field control device 110 comprises a computing device advantageously connected to a transmission device. For example, the computing device may comprise a hand-held computing device such as a personal digital assistant (PDA). Examples of PDA's are Palm m and Palm rv, commercially available from Palm, Inc., Compaq iPAQ Pocket PC, commercially available from Compaq Computer Corporation, and the like. The computing device comprises an operating system, such as, for example, Palm OS commercially available from Palm, Inc., or Microsoft Windows CE commercially available from Microsoft Corporation, or the like. The computing device is operationally connected to an antenna (not shown). The antenna comprises any device capable of transmitting and receiving data, such as, for example, a radio frequency (RF) antenna. In one embodiment of the invention, the computing device and the antenna are contained in one device (e.g., a PDA) capable of both executing a computer program and also communicating with other devices.

[0020] The data tag 120 comprises any device capable of storing digital data. In one embodiment of the invention, the data tag 120 comprises a radio-frequency identification (RFID) tag. For example, the data tag 120 comprises RFID tags such as Tag-it, commercially available from Texas Instruments Incorporated, I-Code smart labels, commercially available from Philips Semiconductors, microID RFID devices commercially available from Microchip Technology Inc., Performa Series RFID devices commercially available from Checkpoint Systems, and the like. In one embodiment of the invention, the data tag 120 is encased in a material or package to protect the data tag 120 from damage, such as, for example, a sealed plastic casing to protect the data tag 120 from weather-related damage. In one embodiment of the invention, the data tag 120 is encased in a flexible material or package to protect the data tag 120 from damage related to the movement or transfer of the tracked entity 140. The data server 130 comprises any device capable of executing computer programs. In one embodiment of the invention, the data server 130 comprises a personal computing device. In another embodiment of the invention, the data server 130 comprises a computer server capable of executing computer programs that collectively serve the needs of one or more computing devices. [0021] The tracked entity 140 comprises a person, an object, or a thing. In one embodiment of the invention, the tracked entity 140 comprises a person where it is advantageous to maintain historical information about that person, such as, for example, a hospital patient, a child, an airline traveler, an employee, and the like. In one embodiment of the invention, the tracked entity 140 comprises an object where it is advantageous to maintain historical information about that object, such as, for example, livestock, a household pet, a shipping package, an automobile, and the like. In one embodiment of the invention, the tracked entity 140 comprises an object where it is advantageous to maintain historical information about the person in possession of that object, such as, for example, a credit card, a passport, an identification card, and the like. The data tag 120 is attached to or associated with the tracked entity 140 to advantageously remain with the tracked entity 140, as the tracked entity 140 changes its location. For example, if the tracked entity 140 is a hospital patient, the data tag 120 may be maintained on a plastic bracelet on the wrist of the patient. As another example, if the tracked entity 140 is a cow, the data tag 120 may be maintained in a protective housing attached to the ear of the cow. As another example, if the tracked entity 140 is a shipping package, the data tag 120 may be maintained in an adhesive package attached to the shipping package.

[0022] Figure 2 illustrates a block diagram of a distributed database system 100, according to aspects of a particular embodiment of the invention. As illustrated in Figure 2, the field control device 110 may communicate with a plurality of data tags 120 and one or more data servers 130 using various communication systems. In one embodiment of the invention, the field control device 110 communicates with the data tag 120 using a wireless communication system, such as, for example, a radio transmission operating at frequencies in the 13.56 MHz band. In one embodiment of the invention, the field control device 110 reads from and writes data to each data tag 120. In another embodiment of the invention, where it is disadvantageous to alter the data on the data tag 120, the field control device 110 only reads data from the data tag 120 and cannot write to the data tags 120.

[0023] In one embodiment of the invention, the field control device 110 communicates with at least one data server 130 using a wireless communication system, such as, for example, a radio transmission operating at frequencies in the 13.56 MHz band. In another embodiment of the invention, the field control device 110 communicates with at least one data server 130 through a communication medium 210. The communication medium 210 comprises a computer network system such as, for example, a Local Area Network (LAN), a wide area network (WAN), the Internet, a satellite communication system, or the like. In another embodiment of the invention, the field control device 110 communicates with the data server 130 through a direct connection, such as, for example, a FireWire, a Universal Serial Bus (USB), or the like. [0024] Figure 3 illustrates a block diagram of a physical division of data proper and data rules 300 within a distributed database system, according to aspects of an embodiment of the invention. As illustrated in Figure 3, the field control device 110 comprises data rules 310 and a field control device program 330. The data tag 120 comprises data 320. The data 320 comprises the data proper representing information relating to the tracked entity 140. The data rules 310 comprise the database schema or the data rules and references used to interpret the data 320 into meaningful information about the tracked entity 140.

[0025] In one embodiment of the invention, the data 320 advantageously contains data proper without data rules. It is advantageous to maintain the data 320 with the data tag 120 and to maintain the data rules 310 with the field control device 110. By only having the data proper reside on the data tag 120, less memory space is required, allowing for a smaller data tag 120 to be utilized. A smaller data tag 120 is advantageous in applications where the tracked entity 140 is small. Moreover, by keeping only data proper on a data tag 120, the data 320 is effectively encrypted with respect to a party who gains access to or takes possession of the tracked entity 140, but who does not have access to the data rules 310. Because the data rules 310 are needed to interpret the data 320, a party who gains access to or takes possession of the tracked entity 140, but is not in possession of the data rules 310 can not interpret the data 320 residing on the data tag 120. Therefore, in applications where it is advantageous to have data confidentiality and security, the data 320 cannot be interpreted by a party who does not have access to the data rules 310. Also, by keeping the data 320 with the tracked entity 140, as the tracked entity 140 is transferred or re-located, the data 320 remains with the tracked entity 140. The data rules 310 may be transferred separately than the tracked entity 140 through, for example, the Internet. Therefore, the information relating to tracked entity 140 can be ascertained by reading the data tag 120 on the tracked entity 140 even though the tracked entity 140 has changed locations.

[0026] The field control device program 330 comprises one or more computer programs that operate the field control device 110. The operations of the field control device program 330 comprise interacting with the data tag 120, including writing portions of the data 320 to the data tag 120, reading portions of the data 320 from the data tag 120, and verifying the portions of the data 320 written to or read from the data tag 120. Also, the operations of the field control device program 330 comprise interacting with the data server 120, including writing data to the data server 120, reading data from the data server 120, and reading the data rules 310 from the data server 120. The operations of the field control device program 330 comprise presenting a user interface to the user of the field control device 110. The user interface allows a user of the field control device 110 to access the functions of the field control device 110. For example, the field control device program 330 uses the data rules 310 to interpret the data 320 from the data tag 120 and to present the interpreted data through the user interface to the user of the field control device 110 as meaningful information regarding the tracked entity 140.

[0027] In one embodiment, open source or proprietary data encryption is utilized to prevent unauthorized access to data, or to permit some portion of the data to be accessed while restricting access to other portions. Because the data stored is heavily compacted and because encryption conceals the structure as well as the data proper, a relatively simple key encryption advantageously provides a very high degree of security. In addition, any random key used to decrypt the encrypted information may produce what appears to be validly decrypted information but without providing verification of the validity of the key or the data.

[0028] As illustrated in Figure 3, the data server 130 comprises the data rule 310 and a database system 340. In one embodiment of the invention, the database system 340 comprises a database management system (DBMS) or a database manager, such as, for example, Microsoft Access, Microsoft SQL Server, DB2 from IBM, database management products from Oracle and Sybase, and the like. A DBMS is a computer program that enables one or more computer users to create and access data in a database. The DBMS manages user requests (and requests from other programs) so that users and other programs are free from having to understand where the data is physically located on storage media and, in a multi-user system, who else may also be accessing the data. In handling user requests, the DBMS ensures the integrity of the data (that is, assuring that the data continues to be accessible and is consistently organized as intended) and security (making sure only those with access privileges can access the data). A conventional type of DBMS includes a relational database management system (RDBMS). A conventional type of user and program interface for the DBMS is the Structured Query Language (SQL). Another example of a DBMS includes the object-oriented database management system (ODBMS). In one embodiment of the invention, the operation of the database system 340 comprises storing and maintaining the data read from one or more data tags 120 by one or more field control devices 110 and transferred to the data server 130. In one embodiment of the invention, the operation of the database system 340 comprises statistical manipulation and analysis of data received from one or more data tags 120 for presentation to one or more users of the data server 130. In one embodiment of the invention, the operation of the database system 340 comprises data mining. Generally, data mining is sorting through data. Thus, in one embodiment of the invention, the database system 340 can be advantageously used for data mining to identify patterns and establish relationships relating to one or more tracked entities 140.

[0029] As illustrated in Figure 3, the data 320 resides on the data tag 120. In one embodiment of the invention, the data 320 is advantageously stored in a manner to reduce the required memory space on the data tag 120. The data 320 comprises data fields. Data fields represent each category of information about the tracked entity 140, such as, for example, serial number, location, owner, and the like. The data fields comprise one or more bits of data. In one embodiment of the invention, the data fields advantageously use substantially the least amount of bits required to represent the data associated with the data field.

[0030] In one embodiment, the data tag 120 comprises a data tag header. Each data tag 120 is initialized before first use. For example, the data tag 120 is initialized with three 32-bit blocks of data (i.e., 3 DWORD values) using a structure appropriate for the information stored about the tracked entity 140. For example, the data structure may include fields for hardware version number (8 bits), company name (20 bits), software version number (14 bits), software program identification number (14 bits), software program revision number (8 bits), expiration flag (2 bits), a count or date (22 bits), a date/time format (3 bits), a use hard lock flag (1 bit), a usage and access flag (i.e. in house use or for export use) (1 bit), and multiple tags field (3 bits). Therefore, the total requirement for the data structure, in this example, is 96 bits or 3 DWORDs. Each value for a field is supplied by the software on the database system 340. Although the actual values intended for storage may take several forms, such as integers or short integers, the data is restructured to fit the 96-bit structure. An example of the data restructuring methods are disclosed herein. In one embodiment of the invention, multiple data tags 120 are associated with a single tracked entity 140. As an example, if multiple data tags 120 are created (i.e., as indicated by the multiple tags field being greater than 1), the first data tag 120 initialized has the multiple tags field set to 2, with each subsequent tag in the set receiving the value 3. Alternately, if only a single data tag 120 is used, the multiple tags field is set to 1, while a value of 0 indicates a single, packed tag that cannot be expanded.

[0031] Continuing with the foregoing example, once the data tag 120 is initialized, the data tag 120 is available to be written to or read from. To write data to the data tag 120, a data record is first created. The field control device program 330 creates a record in program memory before writing the record to the data tag 120. As an example, the process of creating a record comprises initializing an empty record block, setting the fields for data size, item count, items remain, data pointer, and item count pointer to 0. Then, the program writes the 7-bit report ID to the record block, increments data size by 7, and sets data pointer to the end of the report ID. Other fields are written in a manner appropriate for writing that particular field. The field control device program 330 also comprises programs for processing data. The programs for processing data parse the data set while performing a comparison between the available space on the data tag 120 and the space required to write the data record. The data set may advantageously be split into two or more records, with each subsequent record being written to the next data tag 120 in the series of multiple data tags 120. Once the field control device program 330 has created a data record, and has processed the data, the data is written to the data tag 120 by transmitting the data from the field control device 110 to the data tag 120. In one embodiment, reading the data from the data tag 120 is the reverse process of writing to the data tag 120, with the exception that during a read, a data record is neither created or deleted on the data tag 120.

[0032] In one embodiment of the invention, numerical values, such as integers and floating point number, are advantageously stored in a minimum significant digits format. In one embodiment, integer values are stored as integers using the smallest bit-size required by the defined value range with negative integers defined by a flag bit. For example, an integer with a permitted data range of 0 to 100 requires 7 bits of storage while an integer with a permitted data range of 0 to 25 requires 5 bits of storage. Therefore, in this manner, storage space is reduced from a standard integer value storage requirement which is normally 32 bits to cover the predefined range of - 2147483647 to 2147483647. For example, in an embodiment of the invention where the tracked entity is a cow, 32 bits may be used for unique animal identification (ID) to represent over 4 billion unique animals, 8 bits may be used for the cow's country code representing 256 different countries, and 22 bits may be used for the cow's ranch ID to represent over 4 million different ranches.

[0033] In one embodiment, floating point values, such as decimals and fractions, are stored as integers with the data rules 310 defining a conversion scheme from the stored integer value to the floating point value. For example, a floating point value such as 123.4, within a permitted data range of 0 to 999.99, would be stored as 12340, requiring 13 bits of data space. Therefore, in this manner, storage space is reduced from a standard floating point value storage requirement which is normally 64 bits to cover the predefined range of-0.9999999999 x 10¹⁹ to 0.9999999999 x IO²⁰. [0034] In one embodiment, date values are stored in 12 bits, and represent the number of days elapsed since a root date. Thus, a 12-bit value advantageously represents over 11 years. For example, if January 1 , 2000 is used as the root date, January 1, 2000 is represented by 0 and January 17, 2000 is represented by 16. In this manner, the space requirement for a date value can be reduced in applications where the range of possible dates is known. For example, in an application where the anticipated date range is between January 1, 2000 and December 31, 2000, the dates can be represented by integers in the range of 0 to 365 with January 1, 2000 used as the root date. Therefore, the storage space requirement is 9 bits which is sufficient to represent an integer between 0 to 365. In one embodiment, the root date is not stored with the data proper, and thus, advantageously provides for encryption from a party that has gained access to the data proper representing the date but does not have access to the data rules 310 containing the root date. For example, if the data proper representing a date is 459, the actual date cannot be ascertained unless the party reading the data proper also has access to the root date.

[0035] In one embodiment, time values are stored in 11 bits, and represent the minutes that have elapsed since midnight. In another embodiment, time values are represented by the seconds, minutes, or hours that have elapsed since a root time. In one embodiment, the root time is not stored with the data proper, and thus, advantageously provides for encryption from a party that has gained access to the data proper representing the time but does not have access to the data rules 310 containing the root time. For example, if the data proper representing a time is 650, the actual time cannot be ascertained unless the party reading the data proper also has access to the root time.

[0036] In one embodiment, list items are stored as list indexes. In this manner, the size of the individual entries are determined by the size of the total list rather than being stored as values. For example, for a list that contains 10 entries, the selection index is stored as a 4-bit value while a selection from a list containing two dozen entries would be stored as a 5-bit value. In one embodiment, the list of possible list values is not stored with the data proper, and thus, advantageously provides for encryption from a party that has gained access to the data proper representing the selection index but does not have access to the data rules 310 containing the list values. For example, if the data proper representing a selection from a list is 12, the actual list selection cannot be ascertained unless the party reading the data proper also has access to the list and the order of items in the list to determine the 12^th item on the list.

[0037] In one embodiment of the invention, string and text values are stored using a modified EBCDIC (Extended Binary Coded Decimal Interchange Code) or a modified Baudot coding where the resulting encoding requires 5 to 5.3 bits per character of the string. Therefore, the format for storing a string advantageously requires less space to store the characters in a string than conventional coding methods, such as, for example, EBCDIC, Baudot, ASCII, Unicode, and the like. Conventional EBCDIC is a binary code for representing alphabetic and numeric characters. In conventional EBCDIC coding, each alphabetic or numeric character is represented with an 8-bit binary number (i.e. a string of eight O's or l's). Therefore, 256 possible characters (letters of the alphabet, numerals, and special characters) are defined. Conventional Baudot code is a five-bit code capable of representing capital letters, numbers, and certain punctuation characters defined as International Telegraph Alphabet #2. Conventional ASCII (American Standard Code for Information Interchange) code is one of the more common formats for text files in computers and on the Internet. Generally, in an ASCII file, each alphabetic, numeric, or special character is represented with a 7-bit binary number (a string of seven Os or Is); therefore, 12δ possible characters are defined.

[0038] In one embodiment, to store string data in a minimal bit-space, four character sets are defined, each consisting of twenty-nine 5 -bit characters and three shift characters, which are used to switch between character sets. For example, the first character set consists of the twenty-six characters 'A' through 'Z' (capitals only) together with three common punctuation characters (i.e., period, comma and space) which are common to all character sets. The remaining entries in the 32-value set are the shift characters used to change to other character sets. A second character set consists of the twenty-six lower-case characters ('a' through 'z'), a third set provides the integers '0' to '9' plus a number of less common punctuation marks, and a fourth set offers addition entries completing the standard ASCII character set plus a few special characters. However, the specific characters used in each set can be varied according to language or other requirements. Moreover, if advantageous, a less compact alphabet set may be employed.

[0039] As discussed herein, the tracked entity 140 comprises a person, an object, or a thing, where it is advantageous to maintain historical information about the tracked entity 140. In one embodiment of the invention, the tracked entity 140 comprises a cow. The data tag 120 is encased in a plastic housing, or other flexible protective material, to protect the data tag 120 from damage due to weather conditions or movement of the cow. The data tag 120 is attached to the cow, for example, attached to the cow's ear, and remains with the cow throughout the cow's life. The information regarding the cow is maintained and updated by the field control device 110. The data 320 comprises information such as, for example, the cow's unique animal identification, the cow's country code, the cow's ranch identification, and the like.

[0040] Figure 4 illustrates a process diagram of data tag conversion during product processing 400, according to aspects of a particular embodiment of the invention. Figure 4 illustrates the particular embodiment of the invention where the tracked entity 140 comprises a cow 440 associated with the data tag 120. The cow 440 is subjected to product processing 410 which converts the cow 440 to one or more processed beef products 450. In one embodiment, the product processing 410 is performed by a meat packer, or the like. About the time the cow 440 is processed by the meat packer, a data tag conversion to product label process 420 converts the data tag 120 associated with the cow 440 to one or more product labels 430 associated with the one or more processed beef products 450 from the cow 440. [0041] In one embodiment, the data tag conversion to product label process 420 comprises any process where a portion of the information on the data tag 120 is placed on another form of identification. In one embodiment, the data 320 is read from the data tag 120 and converted to a fixed form of identification to be attached to each package of beef products 450 containing meat from the cow 440. The fixed form of identification may include various other information not on the data tag 120, such as, for example, information regarding the meat packer, the date and time of the processing, and the like. The product label 430 comprises a form of identification using any system of representing data about a package, such as, for example, a bar code label. A bar code is generally a small image of lines, bars and spaces that is affixed to objects such as retail store items, identification cards, and postal mail to identify a particular product number, person, or location. The code uses a sequence of vertical bars and spaces to represent numbers and other symbols. A bar code reader is used to read the code. The reader uses a laser beam that is sensitive to the reflections from the line and space thickness and variation. The reader translates the reflected light into digital data that is transferred to a computer for immediate action or storage. In one embodiment of the invention, the bar code standard utilized is PDF417 (Portable Data file) which is generally a 2-dimensional type of bar code that can encode up to 1108 bytes of information. Therefore, the bar code, through lines, bars and spaces, represents the data 320 and other data.

[0042] By converting the data tag 120 to a bar code label and attaching it to the package of meat, the source of the meat can be advantageously ascertained from the package. For example, if a certain ranch is identified as afflicted with a certain disease, the meat packages from that ranch can be identified by reading the label on the package of meat, since the ranch identification code is stored on the bar code. In this way, if there is a disease outbreak, the affected packages are identified, and less meat is wasted because the unaffected packages can also be identified and not destroyed. As another example, a grocery store may use the information on the bar codes to perform statistical analysis regarding the meat and determine, for example, which ranches provide a higher quality meat product or a more commercially successful meat product.

[0043] Figures 5a and 5b illustrate two exemplary expanded views of data stored on a data tag, according to aspects of two particular embodiment of the invention. As illustrated in Figures 5a and 5b, the data 320 comprises a data structure 510 and 520. Each of the data structures 510 and 520 comprises a set of bits. As illustrated, each of the data structures 510 and 520 comprises variable field length encoded fields. For example, the data structure 510 comprises data fields 530, 540, 550, and 560, along with other data fields, stored on a 1024-bit data structure. The data fields 530, 540, 550, and 560 comprise variable-sized number of bits. As illustrated, the data field 530 comprises 2 bits, the data field 540 comprises 3 bits, data field 550 comprises 2 bits, and the data field 560 comprises 3 bits. As another example, the data structure 520 comprises data fields 570, 580, and 590 along with other data fields, stored in a 2048-bit data structure. The data fields 570, 580, and 590 comprise variable numbers of bits. As illustrated, the data field 570 comprises 3 bits, the data field 580 comprises 3 bits, data field 590 comprises 2 bits, and the data field 560 comprises 3 bits. [0044] As illustrated, the data structures 510 and 520 comprise data fields that represent data relating to the tracked entity 140 or represent data relating to other data fields in the data structure. For example, the data field 530 may represent an identification code for the tracked entity 140, or the data field 530 may represent information about another data field in the data structure, such as the data field 540. As an example, one data field may indicate whether another data field contains a positive value or a negative value. As another example, if one data field contains a selected list item, another data field may represent the list from which the list item is selected. Figures 5a and 5b also illustrate the transfer of the data 120 comprising the data structure 510 between the data tag 120 and the field control device 110. [0045] In one embodiment of the invention, the data rules 310 can be used as a decryption key to interpret the data 320 regarding the tracked entity 140. The key can advantageously be provided with the entity so that the data 320 can be interpreted without the use of the field control device 110 and the data server 130. Thus, the key is advantageous in situations where the tracked entity 140 is moved from location to location, or purchased by a party, the data 320 pertaining to the tracked entity 140 can be read and interpreted if the key is provided with the tracked entity 140. [0047] The following appendix describes additional details of specific embodiments of the invention. The appendix is intended to illustrate exemplary embodiments of the invention and is not intended to limit the invention. [0046] While the foregoing detailed description has shown, described and identified several novel features of the invention as applied to a preferred embodiment, it will be understood that various omissions, substitutions and changes in the form and details of the described embodiments may be made by those skilled in the art without departing from the spirit of the invention. Accordingly, the scope of the invention should not be limited to the foregoing discussion, but should be defined by the appended claims. APPENDIX

Modified EBCDIC String Storage

The EBCDIC (Extended Binary Coded Decimal Interchange Code) character set originated c early IBM systems and was used on some electronic printers. Characterized by a 5-h character code with a single switch code (commonly 11111b), EBCDIC existed in sever mutually-incompatible versions.

Using standard ASCII codes - while convenient - has the drawback of requiring 7-bits p< character (minimal) to represent data with the first 32 bit codes (00..1F) reserved as contπ characters inherited from teletype codes.

However, instead of defining individual codes for each character and ignoring the obsolel control codes, a modified EBCDIC code set can be defined with four character sets, eac containing 29 characters and three shift characters.

Compact Strings

In order to ensure compact strings, a #define statement flags a lowercase to uppercas conversion. The cost of switching back and forth from CAPS to lowercase - for names, fc example, where the first letter is capitalized - results in a significantly higher-bit per-charact« costs (on the order of 6.5 to 7 bits/char versus 5 to 5.2 bits/char for 'caseless' text).

Field Delimiters

One new provision has been added to this design; the inclusion of a field delimiter fla (identified as eof or end of yield). The field delimiter flag allows multiple strings to b concatenated in a single string field using the eof flag as a separator between strings. Th advantage is simple: rather than identifying separate fields for strings, a single concatenate field uses less space than separate fields.

Three field delimiters are recognized as 'V (CR), '\t' (tab) and '|' while the '\n' (newline character — which commonly appears as the pair '\r\n' - is ignored.

The eof flag (value 26) is found in both char set 3 and 4 but not in char set 1 or 2. This mean that a field delimiter will commonly require two characters as "30 26". However, when a shii (to Char Set 3) is used to identify a delimiter, the system reverts automatically to the previou character set, thus saving a third 5-bit change flag.

Note: a change is required because the two alpha character sets do not have space t< accommodate an eof flag. Overall, this approach adds minimal overhead requirements fo string storage.

While three separate characters are accepted as delimiters on input; on output, a singl< delimiter is selected through a #define statement. Since the output may be displayed a separate fields or as multi-line text, conversion to the final format is left to the end applicatioi design. Char Set 1 (default, upper case)

In this form the first (default) character set consists of the letters A..Z, space and the two mo common punctuation characters (period and comma).

Note: the space, period and comma characters appear in each character set, always with the same char codes. As a precaution, the zero entry in each char set is always a space.

In this schema, character 29 shifts to the second char set, character 30 selects the third char si and character 31 the fourth.

Char Set 2 (lower case)

The second character set duplicates the first but uses lower-case characters a..z.

Here character value 29 shifts back to the first char set while char values 30 and 31 select th third and fourth char sets respectively.

Char Set 3 (numbers and calculation characters)

The third character set provides the numbers 1..9, 0 along with those symbols which ar commonly used in conjunction with numbers.

Here character values 29 and 30 shift back to the first and second char sets while char values 31 selects the fourth char sets. Char Set 4 (punctuation)

Last, the fourth character set provides the 'curse characters' - i.e. punctuation characters whi< are not otherwise provided - as well as three currency symbols. This also provides sev< blank char values which are not assigned but which could, optionally, be used for oth international characters.

Here character value 29 shifts back to the first char set while char values 30 and 31 select th second and third char sets respectively.

Note that the vertical bar (|) character, previously given the value 14, has been removed frc-r the character set since it is now one of the possible (accepted) delimiters. All subsequer characters in the original set have been moved down one position.

Expansion Character Sets

If necessary, this schema could be expanded to include additional char sets by the simpl expedient of using the seven presently unassigned characters in Char Set 4 as selectors.

Thus two five-bit character entries - such as 19h, 12h through 19h, 19h - would shift the entir string to an alternate character set.

Benefits

The proposed 5-bit character set actually has a packing value of 5.5- to 6-bits per character - an improvement over 7-bit ASCII of 78 to 86%. This is based on the assumption that a shil character will be needed, on average, every 10^th character and no more often than every 5* character. While not ideal, this does extend the available storage capacity by a factor of 17 t< 27%. Unfortunately, we'll need to plan this on a 'worst case' basis (17%) although tin implementation can be written to use the optimum encoding in terms of final bit size.

Tests using names and addresses - per the proposed Wins application requirements hav< shown bit char averages on the order of 5.0 to 5.2 (including field delimiters). Alternatives

Open question: whether the zip compression algorithms could be applied to either a 7-t ASCII or a 5-bit condensed string? If so, what degree of compression could be expected?

Implementation

Because condensed strings will need to be displayed on the handheld device when read fro the data tag, the process of converting standard ASCII to and from a condensed bit pattern w be implemented as part of the Palm application.

Condensed String Characteristics

The first n-bits in the condensed string field specify the size (c) of the condensed strii expressed in 5-bit characters. The value of n is dependent on the original string length (s) defined by the client's data structure but the value of n can be calculated as: c = s * 6/5 and 2" ≥c

This makes n the smallest number of bits which can express the defined length s with a ⁶I- character ratio. The actual value stored in the first n bits, however, will be the number of 5-t characters in the condensed string and the actual encoded string length - in bits - will be n-bi plus the value n * 5.

Condensing a String

Condensing a string begins by setting the active character set to the first (default) character s and then locating the first character from the string in the four char sets.

Presumably, a table lookup will be most efficient since, except for the sequences A.. Z, a..z and O..9,for compression efficiency, the characters in the char sets do not follow the standard ASCII order.

However, since char set 1 and char set 2 are essentially the same character sets — one upper case, one lower case — and are mostly sequential, these cases can be conveniently handled in a simpler manner.

Likewise, regardless of the char set, a value ofO is a space, 27 is a period and 28 is a comma. These would be handled both on expansion and condensing without bothering with a lookup or consideration for the active char set. If the character is in the first (default) char set, the character value becomes the first five-t value.

Alternately, if the character is found in the 2^nd, 3^rd or 4^th char sets, the shift character from tl first char set becomes the first five-bit value, followed by the character value while the select* char set becomes the new active char set.

Subsequently, then next character from the ASCII string is located, begirming with the actπ char set and continuing until the entire ASCII string has been processed. After completing conversion, the active char set is reset to the first char set and the length - i five-bit characters - of the compressed string is determined.

Using the formula preceding, the estimated compression length is calculated to determine th bit size required for the length field before the actual compressed length is copied to the b field and prepended to the condensed string.

Expanding a String

The first step in expanding a string is to use the formula described in Condensed Strin Characteristics to determine the bit size of the field containing the condensed size information

With the calculated bit size, the first n bits are converted to an integer c and then the followin c * 5 bits are the condensed string proper.

Next, the active char set is set to the first (or default) char set and the first five bits from th condensed string are read.

In each step, if the condensed character is less than 29, the condensed character is translated t< the corresponding ASCII value from the active char set.

Alternately, if the value indicates a shift to another char set, the new char set becomes th< active char set and the process continues with the next 5-bit condensed character.

SmartWare™ Data Tags

The key functionality of IDComm's SmartWare™ data tags lies in the unique development < a 'distributed database' together with space-minimal data storage formats, the combinatic constituting a patentable art and invention.

Conventionally, a database - as implemented on systems throughout the world virtually sin the invention of the computer and as typified by all systems since punchcards were first used 1 enumerate the US census - contains both data and schema - the latter being the rules ft deciphering the actual data - in a single physical location; i.e., a computer and its associate storage mechanisms.

In the distributed database implemented though IDComm's SmartWare™ technology, distinct departure from the conventional is made by placing the data proper in many individui and uniquely distributed sites while the database schema - the data rules and references fc interpretation - are maintained on one or more centralized servers.

In a conventional database, the data pertaining to a specific record is commonly referred to as 'row' of data while individual fields within each record are identified as 'columns' — terminology which derives most recently from visual spreadsheets (a specialized form c database) and historically from printed ledgers.

In the distributed database format implemented by IDComm's SmartWare™ processes, th data 'rows' have been removed from the centralized database even though the columns - th structure and interpretation of the data - remain centralized.

In this fashion, the data ('row') specific to an individual cow, a medical patient or a shippin container remains with and is accessible from the object which the data record relates tc Further, since the database rules are accessible - variously though the World Wide Web am any Internet connection or - depending on client preferences - only though a local LAN o even an individual machine, interpretation of the data is possible - and implemented - througl an on-site device - typically a PDA/Interrogator but not restricted to such, the data is availabl and usable at remote locations without dependence on fixed installations, network capabilitie or power-grid infrastructure.

In addition, using the SmartWare™ data storage algorithms, individual data elements ar< stored in space-minimal formats as dictated by defined data ranges for fields and othe structural requirements defined by the SmartWare™ system in response to industry o application-specific needs. This is contrasted to industry conventions where 'standard' format (and sizes) always appear as multiple-bytes (multiple 8-bit sizes) following practices originalh dictated by CPU-inherent memory addressing conveniences but since adhered to simply for thi convenience of established practice and standardized references as embodied by contempora programming languages (including embedded machine language operations as well as higher level languages.)

SmartWare™ Features:

• Data remains with the object referenced.

• Data can be transferred with the transfer of the object referenced. • Public data can be readily accessed at remote or distributed locations

• Private data can be encrypted for protection.

• Disposable, one-time encryption keys allow access to private data to be 'sold' as commodity on transfer of the referenced object.

Elements comprising SmartWare™ Data Storage

• Data elements are stored in a referential format such that the 'bits' of informatic comprising the data reference are the minimal size possible according to the principl< of Information Theory. The result of employing such variable data sizes produces distinct savings in storage capacity in circumstances where 'data space' is limited an usage is at a premium. o Selections from lists are stored as list indexes where the size of the individus entries are determined by the size of the total list rather than (per conventioni usage) being stored as values using 'standard' data sizes. I.e., rather than usin a BYTE (8-bit), WORD (16-bit) or DWORD (32-bit) value to store an index, for list containing ten entries, the selection index is stored as a 4-bit value while selection from a list containing two dozen entries would be stored as a 5-b] value. o Numerical values - both integers and floating point values - are stored in minimum significant digits format. Integer values are stored simply as integer using the smallest bit-size required by the defined value range with negativ integers indicated by a flag bit (a two-entry list) where permitted by the recor< definition. Floating-point (decimal fraction) values are also stored as integer (same rules) with the record schema providing a conversion from the store* simple integer to the original decimal value. Advantages are:

■ a single compact format for both integers and floating-point values,

^■ minimal storage requirements dictated by the maximum allowed value. In this form, an integer with an allowed range 0..100 requires 7 bits storag< while a field with an integer range 0..25 is stored using only 5 bits. Conversely a standard integer value is normally 32-bits covering the predefined range: - 2147483647 to 2147483647.

In like fashion, a floating-point value such as 123.4 (with a permitted range o: 0..999.99) would be stored as 12340 (requiring 17-bits). Conversely, standarc floating-point entries are stored as a 64-bit (8 byte) values suitable for the fixed- range -0.9999999999E+19 to 0.9999999999E+20. o In the standard SmartWare™ implementation, dates and times are stored respectively, in 12-bit and 11-bit formats; the first being defined as days elapsed since a root date and the second as minutes since midnight. Conventional date and date/time values (using Microsoft's programming languages) are stored as 32-bit (8 byte) entries. Date and time formats can be varied, however, as required by custom application needs but will follow the principal of minimal size formats. o String (text) values are stored using a modified EBCDIC (or modifii BAUDOT) coding where the resulting encoded strings commonly require 5 5.3 bits/character. This is contrasted by conventional strings which have a fix< size of 8 bits per character for ASCII or 16 bits per character for UNICOE format. While no explicit provisions have been made as yet to support multip languages (per the International UNICODE format), the SmartWare™ te format can be extended for international support by using font pages for no: European character sets.

• Specialty data types can be created as required for custom applications, again followii the practice of storing data in minimal space configurations rather than relying c standard (and wasteful) data structures.

Data Security

• Data can be uniquely encoded and decoded in a highly secure form without beir vulnerable to 'cracking' or decryption without the encryption key. This feature possible because of the nature of the compressed data structure where any 'key' cai potentially, return an apparently 'meaningful' decode without actually restoring tl 'real' data. I.e., without the specific and correct key, once data has been encrypt© there is no way to distinguish an invalid decode from a valid decode.

• A key generation process is used to provide unique, one-time keys ft encryption/decryption.

Summary:

The element in the SmartWare™ process lies in the physical divorce of the data proper (ti database 'rows') from the data rules (the database 'columns') and storing these 'rows' with th objects to which they refer, thus creating distributed storage and making remote access an reference possible and convenient.

Because the media (RFID tags) used to store the distributed data have limited capacities, th packed data-format algorithms discussed provide the means of rendering the theoretic! processes as a practical implementation. While the details of how packed data formats at implemented can vary, the principal of storing data in minimal (bit-size) formats defined by a external schema is uniquely different from the data storage practices used throughout th computer industry. Statement of Work Hand Held Tag Reader

• Overview for handheld

The Hand Held Reader/writer is designed to read and write digital information t 'Tags" (storage units) in a variety of environments anywhere from the jungles of Soul- America to the Icelandic plains and from inside buildings to the heat of deserts. Th device is intended to satisfy a myriad of industries in a myriad of environments. Th Reader/writer Housing should be as rugged as possible to protect the digital electroni components, contained within, that are used to interface with the storage units. Th' Reader/writer is battery powered and will need all the usual indicators and charginj system to satisfy both US, Asian, European and South American power systems. Th computing device, also contained within, must operate on the OS platform. It is ou indent to offer the best on-board computer for the particular job that is to be done. Thi on-board computer must be protected by a membrane of some type to give the unit a much protection from the elements as possible.

Mechanical design • Material

Case and handle

Membrane for OS based unit to seal out environment

Connections for battery charging

Antenna for RF LAN

Antenna for the transceiver

Extension mechanism for Antenna

Thumb trigger for the Transceiver

Environmental conditions

• Des: gn layout

Case and handle

Membrane for OS based unit to seal out environment

Connections for battery charging

Antenna for RF LAN

Antenna for the transceiver

Extension mechanism for Antenna

Thumb trigger for the Transceiver

Environmental conditions

Ergonomics

Electronic components and PCB's Receiver / Transmitter Connection for the LAN LAN RF board LAN RF antenna

Connection for the RS232 and the OS device and the Network OS Device mounting Battery and charging system Charge connector for the OS device Environmental conditions

Testing

FCC Part l5, VDE, CSA

Humidity

Shock and vibration

Operating Temperature Range

Battery Life and charge time Overview for handheld

The unit to be designed is a hand held device that will be capable of working under adverse condition: The temperature range of usage is from -10°C to +55°C. The unit will be produced out of a rugge plastic capable of meeting various environmental conditions and the screen cover will be produced oi of vinyl or membrane type material that will add to the unit's water resistance capabilities. This un will house a variety of different components and will need to be opened and closed at different interval to allow for updates and maintenance.

Changes to the SOW

Any deviation from this statement of work, SOW, must be submitted in writing. The change reques should include as a minimum the following:

• Type of change

• Reason for change

• Cost impacts to the assembly process

• Cost justifications to the change

• Implementation and design impacts

After submission to IDComm, Inc. for approval or disapproval, a response will be in writing and signe< by a company officer.

Mechanical design for the Housing

• Material

Case and handle: The Case and handle are to be designed and constructed of ABS o polystyrene material. Foaming or increasing IZOD is acceptable for environmental reasons. I the design engineer determines the need to utilize a different material, it is up to the Engineer t< request the change in writing. It must be written in such a way to describe the type of materia request and the reason for the change. The material selection must withstand organic oi industrial oils, citric acids, UN and salts or sodium. The color is to be bright Yellow.

Membrane for OS on-board computer to seal out environment: This is a thin Vinyl sheei or flexible membrane that must be sealed to the handle, by heat or, other process. This will allow the touch screen of the Palm style unit to be utilized without any extra effort. Musi withstand organic or industrial oils, citric acids, UN and salts or sodium.

On-Off button Surface: This is a vinyl material or a flexible material that can withstand the Temperature extremes and the handling of it. The unit will be subjected to and must resist oih from industrial or organic, citric acids, UN and salts or sodium. It would be nice to utilize the same materials that are used on remotes for TN's. This material has a good track record.

• Components and systems

Battery and Charger for the RF Units:

1. The battery should be Nickel Hydride or Lithium, and should be 10 to 12VDC to sustain a current of 200mA for 10 to 15hours before recharge. The charger must be able to accept DC from a cigarette lighter and AC from a Wall source. The Wall AC must be 40 to 70Hz and 100 to 130V AC. The AC charger can be external with the same plug for the DC input. The charge time should be 1 to 2 hours. 2. LED lights will show charging and charged. A multi color LED may be used.

3. The Batteries should be accessible for changing out when required. Pressure connections non-soldered connections would be preferable over soldered connections. Off the shelf sty batteries would be preferable over custom ones if possible.

4. Low power will be LED displayed using the same LED's.

Battery and Charger Palm Style Units:

1. Should be split from the DC input charging socket and converted to 4.1 and 6VDC for chargii the Palm Style unit batteries at the same time as the RF unit batteries.

2. LED lights will show charging and charged. A multi color LED may be used.

3. Low Power will be LED displayed using the same LED ' s.

4. A Ferrite core may be required to keep unwanted RF from conducting down the power lin FOR VDE, CSA and FCC.

RF Tag Transceiver:

1. There are two different sources for a finished Transceiver board if it is decided that IDComri Inc. should not to build one. AWID has a 1.5"x3"x0.75" device. The other is TRISYS has 3"x5"x0.5" device.

• AWID

• 382 Route 59, Section 292

• Monsey, NY 10952

• Contact: Donny Lee, President

• 914-369-8800

• TRISYS, Inc.

• 21608 N. 20^th Ave

• Phoenix, AZ 85027

• Contact: Mike Drews, Project Manager

• 623-581-7414 ext. 105

2. Microchip has a parts list with layout instructions.

3. Develop your own Transceiver or proprietary receiver. This is only for companies that hav the background or current capability.

4. It would be advantages to read both the Philips I-Code device and the Microchip 450 and 35 devices.

5. When bidding the contract please specify which unit will be used. IDComm holds the right t change the path with a re-quote.

6. Layout of the board is addressed latter in the SOW.

RF Transceiver for the LAN Device:

1. IDComm has chosen to go with AeroComm, Inc. for OEM supply. They offer a 2GHz Sprea Spectrum device that will fit our unit. The device is a PKLR2400S and is self-contained. 1 takes the ASCII Data and converts to the required RF protocol and sends it to the base uni which re-converts the Data to ASCII for

2. The option to choose another vendor requires IDComm approval.

3. LAN Based unit will be a separate SOW.

• AeroComm, Inc.

• 13256 W. 98^th Street

• Lenexa, KS 66215

• Contact: Mike Hutton, OEM Sales Account Manager

• 800-492-2320 ext. 213 Connection to and from the Hand Held: (See Figure 6)

Antennas

1. The Transceiver antenna is to be mounted into the Plastic shell as shown in Figure 7. If tl antenna can not be mounted change drawings must be approved. The connections to tl antenna can be either spring contact or flex cable with connector plugs. Either way the anteru housing will be built with breakaway considerations. If dropped the antenna can break off ai with minimal effort be re-attached. The antenna is on a slide to allow the antenna to wo outside of the Transceiver unit. This will help prevent intramodulation of data onto tl processing unit.

2. The LAN Transceiver could be accomplished two ways.

2.1 Aero Comm unit PKLR2400s with the antenna built into the PCB. This will make th« handheld more directional but will be less mechanism and no external antenna to get damaged or broken.

2.2 Aero Comm unit LX2400 or PKLR2400; without the PCB antenna which will require cable and antenna to be added to the case and PCB. This will add better range and also will be non-directional. Better solution more material and cost and will be Susceptible to damage. Figure 8 shows the requested layout.

3. Palm VQ antenna is incorporated into the Palm and does not need to be engineered. Will need to see if Hand Spring, Inc. has a similar offering.

Palm / OS Style on-board computer Mounting

1. The Communication device is OS based and will be OEM or off the shelf units. Mechanic! connection to the unit's RS232 port is required. Compression would be a great way to hold the o the shelf unit in place and maybe the OEM unit. This compression will come from the hand] cover compressing the unit into the. base unit. The connector must be able to connect the RS23 and the Charging power for the OS processing unit. A universal connector would be nice, needed, a clamp mechanism may be utilized to hold the unit to the Base.

RS232 wiring

1. The Connection diagram from above demonstrates how the different models will be wired. The RS232 connector for the LAN, via USB port should be at the rear of the handheld for the ability to attach to a single box for charging and communication. Although this is a future option or incorporation, consideration needs to be taken on this go around. Internal wiring will be placed in sucl a manner to prevent internal RF problems and to rninimize cross modulation and capacitance problems Environmental issues should be taken with the USB port by using a cover or something like it. A cove with a plastic strap that is compressed during the assembly process would also be helpful. This way th cover can be replaced after finishing a connection. Ferrite may be required to prevent unwanted RF from conducting out the USB port and radiating. This is for CSA, VDE and FCC rules.

PCB Mounting

1. All PCB's will be mounted by snap in style connection as a primary request. The use of screw would be a last resort. It will be up to the design engineer to come up with the easiest solution the mounting issue. There will be customers that buy an IDC 1001 and want to upgrade to a EDC3001 handheld. We would like for them to just plug and play. It would be optimum for th PCB's to be removed as easily as it was installed Case, Cover and Antenna mechanics

1. Figure 9 is the proposed assembly request. A different one can be used with written authorization.

1.2 The handle will snap into place with a ball end type hinge. The ball hinge can be accomplishe also by any other means. IDComm prefers this style hinge. The handle of the cover will be screwed into place with special star type screws. This will protect companies from having employees tamper with the handheld unit and also will help prevent the theft of the Palm style units. If a snap in style were created it would be nice to have a special tool to unsnap the handle from the base. The handle must be designed to give maximum strength with mimmum weight and bulkiness. The finished unit must withstand a 4-foot drop test.

1.2.2 The Membrane should be a separate weatherproof snap in. This component will have large ware factor and will need to be replaced every so often. If this cannot t accomplished than the membrane can be heat-sealed to the handle and the handle wi need to be replaced. This will cause problems for the customer, in having to remove completely from the base unit and also causes problems with the button.

1.2.3 The Button will be attached to the switch and should be mounted in a way th« replacement of the entire unit can be accomplished at the customer level. This butto should be engineered to fit with off the shelf components.

1.3 The Base unit will have the necessary area to mount all required components and PCB's. Th base should be designed with rounded sculptured looks and should not very too much from th concept drawing. The base unit must allow the antenna to become dislodged freely whe dropped. This is to minimize the damage to both parts. The slide mechanism should b designed in a manner to allow the antenna to be snapped back into place after being dislodgec The slide mechanism should also allow for maximum extension without allowing the antenn to be extended past the end of the base.

1.4 The antenna housing should have the wire antenna molded into it. This is the preference Other alternatives will be eligible for review. The antenna housing will contain the antenn; and the connections from the antenna to the base. Flex or ribbon cable is one way o connection. Spring mounted pins may be another style of connection.

Environmental Conditions and Requirements

The unit will pass a variety of tests without failure to the operation of the handheld.

Drop Test from 4-feet on two corners and handle. The antenna closed and extended.

UV radiated to pass 4-years in direct sun. This test can be simulated or enough dat; shown that the unit will not decompose except for the membrane and switch.

Vibration per MIL-STD-202 with 5,000 cycles continuous.

Moisture Resistance per MIL-STD-202 method 106 except the temperature will b<

40°C and the relative humidity is to be 90%. Test duration to be lOOhrs.

Temperature extremes from -10°C to +55°C in operational mode.

Life test lOOhrs at +55°C in operation condition.

ESD at 15KV 3 times in 10 sec. 30KV one time. Must remain operational. Electronic Conditions and Requirements

Radiated susceptibility at 50N/m 5MHz to 3GHz. This is to I done on the IDC5001.

Conducted susceptibility MIL-STD-461B

FCC rules and regulations for part 15

CSA

NDE

(See Figure 7)

(See Figures 8 and 9)

Overview

To develop a generic software called SmartWare ™ that is windows based, (Unix is an option), 1 companies in need of external as well as internal tracking of information on devices, systems services. This software is designed for MIS departments and will be used to build the required fie information base, which is converted into data, files for reading and writing to RF Tags with memo called 3D»ID™. Then to enable this data file and the accompanying SmartWare ™ to be uploaded \ multiple ways into Hand Held RF data collection systems that will be used by employees when writii and reading to the 3D«ID™ devices. The information can be written to each 3D»ID™ unit that carrying the ID requirements of the company-coded system. This will allow multiple RF Taggii devices to be in the same vicinity as the 3D«ID™ devices and not breach security and miss writes. T goal is to allow firms to place lOOlbs of information into a lib box. There is approximately 600 1250 bits of storage capable on the 3D*ID™ devices. This converts to 30 to 60 words of storage. Tl software to be developed, SmartWare™ will do the data field compression allowing multiple words ai statements to be placed through this compression onto the 3D«ID™ devices. The units that will car the Data files will vary in memory from 2Megs to 8Megs.

Our Niche Industry Market Types

• Shipping Bill of Lading

• Shipping for Tracking information

• Customs

• Pallet Tracking

• Service and Maintenance systems

• ISO 9000 service and preventative maintenance

• Custom assembly systems

• MRP systems

• Rental company damage tracking

• Livestock Identification tracking

Types of PC Based Systems

• DOS

• Windows (3.1), 95,98,2000 and NT

• Linux

• Unix

Types of Hand Held Protocol

• Palm OS for Palm HI, VII

• Windows CE, Casio

Types of Hand Held Communications

• RS232

• 900MHz SS @1.6M/s

• 2.45GHz SS @1.6M/s

• RF Internet Interface (Palm VII) Types of RF Tag Protocols

• Philips, I-Code™

• MicroID™

• Micro450

• Taglt™

• Performa™

PC Based developer software, SmartWare™

The system software invokes a help Wizard to guide the MIS department through the development the data fields and associated cells, libraries and Cells.

• Monitor how much memory the data files are taking up.

• Helps MIS understand that there will be other firms with hand held reade with multiple company data files in them and that wasting memory is not a go< idea.

• Tag memory level indicator.

• A must for the amount of stringed bits being attached to each category duri development of data files.

• Bit system help for categories.

• This is to allow the developer to utilize each category size economical and to allow for future size increases.

• Special function cells

• These cells which will write ASCII to the chip when required and are for vei special instances where there is no way to data table the entry, i.e. custon clearance number.

• Revision cell

• This is Special cell that allows the older generation tags to be read with newi generation Data.

• Attribute dictionary building and field linking.

• These field modifiers allow various functions to occur during developmer These will cause the fields to become relational and add flexibility to dimension 1 the data being developed.

Tag Memory

The tag has read/write EE-prom based memory and varies from 800 Bits of storage to 1000 Bits < storage. The Micro450 has the capability of being flagged as non-erasable which locks the memoi information permanently. We would like to utilize this under certain conditions.

• Software to be able to flag portions of memory as non-erasable.

• Software to be able to flag all memory as non-erasable.

• Need a fuel cell to be visible on the hand held menu for amount of memory le and to alarm if write is going to exceed the memory available.

• The software will have a wizard to help the MIS department create the require fields and attributes. • ***NOTE: The Wizard needs to keep MIS informed as to how much environmei the data fields are taking up. It should include a bit field table to show the differer types of sizes as shown in below.

Attributes to Fields

• The attribute is an extension to the field, which has multiple characteristics

There should be at least 10 attributes per field.

• Some of these attributes will tie other fields together.

• Some of them may tie the fields to one or multiple categories

• Some may evoke a subroutine or do loop or look up table

The attribute should be a library that is built by MIS and can also have example with the wizard.

REVIEW

The software is designed to read and write to a 1000 bit RF Tag. The written data i information pertinent to the company. The data being read can be ASCII formatted an< transmitted to LAN systems for further processing. This is accomplished through RS232, R] 900MHz, RF 2.54GHz or Internet access via the palm pilot. The software data is what the use creates and is done through a number of steps and questions. These questions create Tag style, and categories along with special fields for ASCII and revision formats. The software data file(s) are intended to be designed and built by MIS at the start in a P( based system. After the Data file has been completed by MIS, our software writes the nev data file and the SmartWare ™ to the Hand held through the RS232 interface or RF link. Thi: data file, which is a *.dat format, can be e-mailed to any location requiring the use of the data The *.dat file can then be uploaded into the Palm for reading the specific companies' tags This can be accomplished as long as the palm and RF reader has SmartWare ™. Readers ma require up to 500 *.dat files for reading incoming tags. We can allow the RF hand held unit! to transfer the required data files as needed to save memory.

• The software is Field driven with each cell carrying its own identifier anc will have link attributes allowing multiple options.

Strategy

1. Develop a working model on the board or paper and prove out the spreadsheet theory.

2. Develop a working model on the PC for review and comment and refinement

3. Take working model and produce a simple demo for marketing.

4. Start developing the Wizard and help functions

5. Dry run with real systems

6. Debug and rerun if required

7. Start the application review process.

Reading Tag Data

These instructions for reading data tags apply to both desktop and Palm-top applications. These program sequences detailed following are diagrammed as a bubble chart (Nisio 2000) in the Read Tag Data.vsd file or as a set of images in Read Tag Data.zip.

Tag Header Structure

Each tag is initialized with three 32-bit blocks of data (3 DWORD values) using the structure described here and in the Data Structures document:

Items Notes

Field Bits Bit Fields Block

Name 96 0 .. 95 3 7.92282E+28 Requires three 32-bit blocks

Hardware Version # 8 0 .. 7 1 256 Hardware version (nominally 1 )

Company 20 8 .. 27 1 1,048,576 Company identifier (assigned by ID Comm)

IDComm Version # 7 28 .. 34 1 / 2 128 ID Comm major version ID Major

IDComm Version # 7 35 .. 41 128 ID Comm minor version ID Minor

Program ID # 14 42 .. 55 65,536 Program identifier (created by program utility)

Program Revision # 8 56 .. 63 256 Revision number (created by program utility)

Expiration flag 64 .. 65 4 expiration flag,

0 = NO_EXPIRE

1 = COUNT_EXPIRE

2 = DATE EXPIRE

Count or Date 22 66 .. 87 3 4,194,304 expiration count or date Date/Time Format 3 88 .. 90 3 8 Date/time format identifier

0 = no date/time stamp

1 = date only

2 = date / hour only

3 = date / hour / minute

4 = date / hour / minute / second

Use_Hard_Lock 1 91 1 T / F Default = FALSE

Usage and Access 1 92 3 2 0 = INJHOUSE, 1 = EXPORT

Multiple Tags 3 93 .. 95 3 8 0 = single tag, no adds, packed record

1 = single with adds, 2 = first tag in set

3 = tag in sequence, 4 = added tag The Date Stamp is the Zulu date (GMT) expressed as days since 1/1/00 - i.e., a value of 0 would be January 1^st, 2000. This truncated date format is good for a little over eleven years; adequate for this first generation of data tags, this format will be supplanted in later versions with a less restricted size.

The Time Stamp is expressed as minutes since midnight (Zulu or GMT). For example, assume the record is being written at 12:26 PM PST. This is 20:26 hours GMT or 1226 minutes since midnight GMT. (Range: 0..1439)

Regardless of the Date/Time Format specified, this initial Time Stamp is always written in minutes since midnight GMT. If a multiple tag set is being created - i.e, if the Tag_Use_Count field from the project database is greater than 1 - the first tag initialized has the Multiple Tags field set to 1 with each subsequent tag in the set receiving the value 2. Alternately, if this will be a single tag, the Multiple Tags field is set to 0. If tags are later added to a single tag or a multi-tag set, the Multiple Tags field is set to 3

Get Tag Type (Identifying the Tag Type)

1. The first action is to read the header block from any tag (blocks 1..3)

2. If the Tag_Use_Flag is Multiple, proceed with the Read Tags operation; if Single_Packed, proceed with Read Single.

Read Tags (Reading a Tag Set)

The first action in reading a tag set is to identify the tags comprising the set.

1. Extract the Company identifier, Program ID and Program Revision numbers

2. Query all tags using the Company, Program ID and Program Revision values.

3. From each tag, read the Tag ID, Next Tag ID (block 4) and Previous Tag ID

(block 5).

Note: the first tag in the set (Multiple Tags = l or 2) does not have a previous tag and block 5 will contain other data.

4. Create an ordered set of tags from the tag IDs. Loop to Step 2 and continue until no additional tags are found.

5. Are there any gaps in the tag order? I.e., any tags identified by previous or next entries but not found. If none, proceed to Read Tag Data.

6. Search for missing tags, querying by tag ID. If any tags are found, loop to Step 3.

7. If referenced tags cannot be found, issue a warning and log the tags as lost.

8. Proceed to Read Tag Data Read Tag Data

Tags are read in the order the set was created. The data from each tag is read into a Record_Block allocated in memory. The data is read raw and parsed only after all tags are collected.

1. Read the first tag in the set, reading blocks 5..32. If the first tag is missing, begin with Step 4.

2. Append the data to Record_BIock

3. Is there a next tag in the set? If not, continue with Prepare Data Record

4. Read the next tag in the set, reading blocks 6..32.

5. Append data to Record Block.

6. Append 32 zero-bits (one block of O's) to the Record_Block. This is used to pad all tag records to the same size.

7. Loop to Step 3.

Prepare Data Record

1. Use the Program ID and Program Version number to identify and retrieve the program data structure.

2. If the program data structure is not available, store the data record for transfer to a database and Exit.

3. Proceed to Parse Transaction

Parse Transaction

Now that all of the data records are in a memory block (Record_BIock) the retrieved information can be parsed into individual transaction records.

1. Begin by setting Block_Offset, Record Offset, Item_Count and Field Count as zero.

2. Beginning at the Record_Offset, read the Report ID from the first seven bits; increment Block_Offset and Record_Offset.

3. If the Report ID is not zero, continue with Step 6

4. Check Record_Offset. If this is not the last tag, increment Record_Offset to the next tag boundary (28 DWORDs) and loop to Step 2.

5. If this is in the last tag, then everything' s done; Return.

6. Retrieve the report structure from the program data.

7. If Date/Time Format = 0, proceed to Step 12

8. Read the timestamp from Record Block; the size of the timestamp is determined by the timestamp format in the program data structure. 9. Are all bits in the timestamp Is? If so, this is a flag identifying a split record and all further data fields are appended to the existing transaction record. Continue with Step 11.

10. Initialize a new record using the Report ID and timestamp retrieved from the Record Block.

11. Increment Block Offset and Record Offset.

12. Read the 7-bit Field_Count from the Record_Block; increment Block_Offset and Record_Offset.

13. Read the 7-bit field ID from the Record_Block; increment Block Offset and Record_Offset.

14. Get the data type and size from the report structure.

15. Read the field data from the Record Block; increment Block_Offset and Record_Offset; increment Item_Count.

16. Convert raw data per field data requirements

17. If Item Count is less than Field_Count, loop to Step 13.

18. At the end of the transaction, if Record Offset is not at the first of a 32-bit boundary, increment to 32-bit boundary.

19. Set Block_Offset, Item_Count, Field Count to zero.

Read Single

1. Read data blocks from tag

2. Extract Report ID from data record as first 7 bits.

3. Retrieve report structure

4. If report structure found, proceed to Step 6

5. Store data for later analysis, then exit.

6. If Date Time Format = 0, proceed to Step 8

7. Read timestamp per report structure

8. Read first data element, increment Record_Offset

9. Read next data element, increment Record Offset

10. If next data element, loop to Step 9

11. Done, return Writing Tag Data

These instructions for writing data tags apply to both desktop and Palm-top applications. These program sequences detailed following are diagrammed as a bubble chart (Nisio 2000) in the Write Tag Data.vsd file or as a set of images in Write Tag Data.zip.

Initializing the Tag

Each tag is initialized with three 32-bit blocks of data (3 DWORD values) using the structure described here and in the Data Structures document:

₅ Reserved Bits Bits Bit Fields Block Notes

Total 96 0 .. 95 3 7.92282E+28 Requires three 32-bit blocks

Hardware Version # 8 0 . . 7 1 256 Hardware version (nominally 1)

Company 20 8 . . 27 1 1,048,576 Company identifier (assigned by ID Comm)

IDComm Version # 7 28 . . 34 1 / 2 128 ID Comm major version ID

Major

IDComm Version # 7 35 . . 41 2 128 ID Comm minor version ID

Minor

Program ID # 14 42 . . 55 2 65,536 Program identifier (created by program utility)

Program Revision # 8 56 . . 63 2 256 Revision number (created by program utility)

Expiration flag 2 64 . . 65 3 4 expiration flag,

0 = NO_EXPIRE

1 = COUNT_EXPIRE

2 = DATE_EXPIRE

Count or Date 22 66 .. 87 3 4,194,304 expiration count or date

Date/Time Format 3 88 .. 90 3 Date/time format identifier

0 = no date/time stamp

1 = date only

2 = date / hour only

3 = date / hour / minute

4 = date / hour / minute / second

Use_Hard_Lock 1 91 1 T / F Default = FALSE

Usage and Access 1 92 3 2 0 = IN_HOUSE, 1 = EXPORT

Multiple Tags 3 93 .. 95 3 8 0 = single tag, no adds, packed record

1 = single with adds, 2 = first tag in set

3 = tag in sequence, 4 = added tag Each of these values will be supplied by the program script from the database. While the individual values supplied by the database will be integers or short integers, these values must be reduced to the Least Significant Bits - not bytes - per the design specification and then packed to create the 96-bit data structure.

If a multiple tag set is being created - i.e, if the Tag_Use_Count field from the project database is greater than 1 - the first tag initialized has the Multiple Tags field set to 2 with each subsequent tag in the set receiving the value 3. Alternately, if this will be a single tag (with expansion permitted), the Multiple Tags field is set to 1 while a value of 0 indicates a single, packed tag which cannot be expanded.

Tag Data Header

1. Create a 96-bit (3 DWord) memory block, set bits to 0

2. Retrieve Hardware Version from registry, format as 8-bit value, write to bits 0..7

[HKEY_LOCALj LACHINE\SOFTWARE\IDComm] "Hardware Version"

3. Retrieve Company ID from registry, format as 20-bit value, write to bits 8..27.

[HKEY_LOCAL_MACHINE\SOFT ARE\IDComm\Company ID] "Company ID"

4. Retrieve IDComm Major Version # from registry, format as 7-bit value, write to bits 28.34. [HKEY_LOCAL_MACHINE\SOFT ARE\IDComm] "Maj or Version"

5. Retrieve IDComm Minor Version # from registry, format as 7-bit value, write to bits 35..41. [HKEY_LOCAL_MACHINE\SOFT ARE\IDComm] "Minor Version"

6. Retrieve pro j ect i D from project schema file (.idw file), format as 14-bit value, write to bits 42..55.

7. Retrieve pro j ect revision # from program schema file, format as 8-bit value, write to bits 56..63.

8. Retrieve the Expiration Flag value from registry.

[HKEY_ OCA _MACHINE\SOFTWARE\IDComm] "Expiration Code"

9. XOR the retrieved Expiration Flag with the Company ID value, format as 2-bit value, write to bits 64..65.

10. Retrieve the Expiration Count value from the registry.

[ HKEY_ OCAL_MACHINE\SOFT ARE\IDComm] "Expiration Value"

11. Check Expiration Code flag as: o NO_EXPIRE (0) - set bits 66..87 as O's (i.e., leave as O's) o COUNT_EXPIRE (1)

1. format the encoded Expiration Count value as a 22-bit value,

2. write to bits 66..87. o DATE_EXPIRE (2)

1. get the current date as days since Jan, 1 , 2000

2. XOR the Expiration Count (from registry) with the Company ID 3. add the decrypted Expiration Count to the current date

4. XOR the result with the Company ID

5. format as a 12-bit value, write to bits 66..77.

12. Retrieve the timestamp f ormat from project schema file, format as 3-bit value, write to bits 88..90.

13. Retrieve use_hard_iock flag from the project schema file, format as a Boolean flag (1-bit), write to bit 91.

Note; the use_hard_lockflag not presently provided — simply write the flag as FALSE (0)

14. Retrieve sage and access flag from the program schema file, format as Boolean flag (1-bit) where IΝ HOUSE = FALSE (0), EXPORT - TRUE (1), write to bit 92.

Note: the usage _and_access flag is not presently provided - simply write the flag as IN_HOUSE (0).

15. Format the tag use count value as a three-bit value, write to bits 93..95, proceed to Initialize Tag.

Initialize Tag

1. Set tag_count to 1.

2. Write the 3 32-bit header blocks to the tag

3. If tag_use_count equals 0 (Single_Padded), soft lock blocks 1..3, write O's to all remaining blocks, do not lock, proceed to Check Tag.

4. Soft lock blocks 1..2.

5. Read and store the tag ID.

6. If tag_usθ_count is equals 0, write O's to block 4 (Next Tag D3), do not lock, proceed to Check Tag.

7. If tag_αount is greater than or equal to tag_use_count, proceed to Link Tags.

8. Select next data tag.

9. Increment tag_count.

10. Loop to Step 2.

Link Tags

1. Select the first tag in set.

2. If this is the last tag in the set, write O's to block 4 (Next Tag ID), do not lock, proceed to Step 5.

3. Write the Tag ID for the next tag in the set to block 4, lock block 4. 4. If this is the first tag in the set, write O's to block 5 (Previous Tag ID), do not lock, proceed to Step 7.

5. Write Tag ID for previous tag in set to block 5 (Previous Tag ID), do not lock.

6. If this is the last tag in the set, proceed to Step 8.

7. Select the next tag in the set, loop to Step 2.

8. Write Tag ID(s) to database along with Program ID, Revision # and flag set as Initialized Only.

9. If a data transaction has been specified, proceed to Check Tag.

10. Done, exit.

A data tag or data tag set may be initialized with or without actual data. While a default data script is created - at the time the program data structure is finalized - to write all data fields in the structure, the client may or may not wish to use this script at this time. If there is no program script to run at this time, the process of initializing the data tag or tag set is complete.

Linking Tags

For a single data tag, shown following, block 4 is unlocked but is reserved to allow additional tags to be added to the set if and as required. Block 5 is also blank and unlocked but this block will be used for data.

For a multiple tag set, the following shows a set of four data tags, the header blocks and tag IDs written to each.

In the first data tag, block five is still blank and unlocked, ready for information to be added. In the fourth (last) data tag, block 4 remains open, allowing another data tag (or tags) to be added to the set as necessary.

Check Tag

This is the entry point whenever data is written to a tag either as a revision record on multiple tag sets or, for a packed, single tag, when existing fields are overwritten.

1. Check the Expiration Flag (bits 64..65).

2. If the flag is DATE_EXPIRE (2), go to Step 5.

3. If the flag is COUNTJEXPIRE (1), go to Step 7.

4. If the flag is NO_EXPIRE (0), go to Step 10.

DATE_EXPIRE

5. XOR the date value (bits 66..77) with the Company ID. If the result is earlier than the current date, issue a date expiration message and exit.

6. Retrieve the Warning Days value

[HKEY_LOCAL_MACHINE\SOFTWARE\IDComm\Company ID] "Warning Days"

If the number of days remaining is less than the Warning Days, issue an expiration warning. Proceed to Step 10.

COUNT_EXPERE

7. XOR the count value (bits 66..87) with the Company ID. If the result is zero, issue a expiration warning and exit. 8. Decrement the result, XOR with the Company ID, unlock block 3, reset the count value in bits 66..87, relock block 3.

9. Retrieve the Count Warning value.

[HKEY_LOCAL_MACHINE\SOFTWARE\IDComm\Company ID] "Warning Days" If the count value is less than the Count Warning value, issue a count expiration warning.

NO_EXPIRE

10. Flag all data items in the transaction record as Ready.

11. If the tag__usa_count equals zero (Single_Packed), go to Single Tag.

12. Go to Check Space.

Check Space

The Check Space routines check the tag set to determine how much space is available.

1. Set the Split_Record flag to FALSE.

2. Find first tag in set.

3. Set the start point at Block 5. Blocks 1..3 are the header, block 4 is always reserved for a tag ID link even though this block will be empty on the last tag in a set or in a single tag. Block 5, however, if blank, may be used on the first tag in a multi-tag set or on a single tag.

4. If this is a single tag, expandable, go to Single Tag Set. Otherwise go to Multi- Tag Set.

Single Tag Set

1. Check Block 4 to determine if an additional tag has been added to create a set. If so, treat as a Multi-tag Set.

2. Search for free space

3. Set Available_Size

4. Set Current_Tag_ID to the tag ID.

5. Set Next_Tag_ID = 0

6. Set Next_ Size = 0

7. Proceed to Create Record

Multi-tag Set

1. Search for first tag with free space

2. Set Available_Size

3. Set Current_Tag_ID to the tag ID.

4. Find the next tag in the set. 5. If the next tag was not found (or damaged, etc), o Set Next_Tag_ID = 0 o Set Next Size = 0 o Go to Create Record

6. Search for free space

7. Set Next_Size

8. Set Next_Tag_ID to the tag ID.

9. Set Next_Tag_ID = 0

10. Check Next_Size; if 0, then set Next_Tag_ID = 0

11. Proceed to Create Record

Create Record

The Create Record subroutines start the process of creating a record in memory before writing the record to the data tag.

1. Initialize an empty record block.

2. Set Data_Size, Item_Count, Items Remain, Data_Pointer and Item_Count_Ptr to zero.

3. Write the 7-bit Report ID to the Record_Block, increment Data_Size by 7 and set Data Pointer to the end of the Report_D3.

4. If Date Time Format greater than 0, go to Step 10

5. Set Data_Size to the size specified by the program's Date/Time Format.

6. If SplitJRecord is TRUE, set all bits in the timestamp to 1 s. This is a flag for identifying the second half of a split record. Proceed to Step 8.

7. Create a timestamp using the format specified.

8. Copy the timestamp to the Record_Block.

9. Set Data_Pointer to the end of the timestamp; set Item CountJPtr to Data Pointer.

10. Copy Item_Count (7 bits) to Record_Block,

11. Set Data_Pointer to end of Item_Count. At this point, Item_Count is zero but this value will be overwritten presently.

12. Continue with Process Data

Process Data

The Process Data routines parse the data set while performing a comparison between the available space on the data tag(s) and the space required to write the data record. If necessary, the data set will be split into two records - on a best-fit basis - with the second record written to the next tag in the set.

1. Find the first data element in the set.

2. Set Item Size to zero.

3. Is the data type a folder? If so, flag the item as Ignore and proceed to Step 12 (Find next data element).

4. Is the data type a string? If so, get Item_Size from the Modified EBCDIC subroutine. Otherwise, get Item_Size from the program script. See Item Size, following.

5. Increment Item_Size by seven (7) for the field identifier size. 6. If Item_Size is greater than Available_Size, increment Items Remain and proceed to Step 12.

7. Decrement Available_Size by Item Size.

8. Flag the item as Processed.

9. Increment Item_Count.

10. Write the 7-bit field ID to Record_Block, set the Data_Pointer to the end of the field ID.

11. Write the item data to the Record_Block, set the Data_Pointer to the end of the item data.

12. Find the next data element (skip all entries not flagged as Ready).

13. If next data element is found, loop to Step 2.

14. Use Item_Count to overwrite the original Item_Count in the Data_Record with the new value.

15. Proceed to Write to Tag

Write to Tag

The task of actually writing the data to the tag is relatively straightforward

1. If Item_Count equals 0, there is no data in the record - Return.

2. If Items_Remain is zero, continue with Step 4.

3. If Items_Remain is greater than zero but Next_Tag_ID equals zero (for either a single tag or a multi-tag set), issue an error message (Insufficient Space) and allow the user the options to: o add a new tag (or tags) to the set - see Expanding a Tag Set. o exit without completing the transaction

Following this option, the process of creating the data record and writing the tag starts again with the Check Space provisions. In this fashion, the first half of a split record is not created unless there is reasonable space to write the second half (i.e., there is an additional tag available). See Inadequate Space following

4. Write Record_Block to the data tag (Current_Tag_ID)

5. If the Use Hard Lock flag is set (TRUE), permanently lock all blocks used; otherwise set the lock bits for each block.

6. If Items_Remain equals zero, Return; that's it, all done.

7. Lock any remaining blocks on Current Tag lD. Since the current record will be continued on another tag, any space remaining on the present tag must be locked to prevent later attempts to use this tag.

8. Set Current Tag D to Next Tag.

9. Set Items Remain to zero, set First Trans action to FALSE, set Split_Record to TRUE.

10. Return to Create Record to process remaining fields

An Example:

Data is written to a tag beginning with the first empty block following block 4. The first record written begins with the Record ID value as the first 7 bits of the data record, followed by the Field Count (the number of fields in the transaction) and then the field identifier of the first data field. Following the field ID, the field data varies in length according to the data type and the program specifications. Next, following the field data, another 7-bit field ID is followed by the corresponding field data and so forth until all fields have been written.

For example, an initial data record might look something like this:

Report field cut field ID field field field field ID field ID data π> data data

7 bits 7 bits 7 bits size 7 bits size 7 bits size varies varies varies

Alternately, if this is a change data record, the data will again begin with the Record ID followed by a date/time stamp as the next w-bits of the record (n is determined by the Date/Time Format specified) and might look something like this:

Report D3 timestamp field cnt field ID field data field ID field data

7 bits n bits 7 bits 7 bits size vanes 7 bits size varies

If a transaction record is too long to fit in the available space, the transaction may be broken and written ύs two records with the second record on the next tag.

Adding Tags

Expanding a tag set is essentially the same for a multi-tag set or a single tag (expandable).

1. Check the new tag, retrieve the tag ID as New_Tag_H)

2. Confirm that the new tag is blank

3. On error, post an error message and allow the user to: o try a new data tag o return to editing the data o cancel the transaction

4. Check Block 4 on original tag for a tag ID to determine if this is a multi-tag set.

5. If this is a single tag, read Last_Tag_ID from the current tag; if a multiple tag set, find the last tag in the set and read Last_Tag_ID.

6. Read the header blocks from the tag identified by Last_Tag_ID

7. Write New_Tag_ID to Block 4 in Last_Tag_ID, lock Block 4.

8. In the header data, set Multiple Tags to 4 - indicates an added tag, not in the original set.

9. Write header block to New_Tag_ID, soft lock blocks 1..3

10. Write Last_Tag_ID to Block 5 on New TagJDD

11. Lock block 5 on New_Tag_ID

12. Write O's to Block 4 on New_Tag_ID, do not lock

13. Write O's to all remaining blocks, do not lock

14. Exit

Single Tags (Packed Data)

Single tags with packed data records require a different treatment, thus:

1. Initialize Record_Block in memory (29 DWORDs).

2. Set Data_Pointer to 0

3. Write Report D to Record_Block

4. Set Data_Pointer to end of Report ID 5. If Date/Time Format equals 0, proceed to Step 9

6. Format timestamp per Date/Time Format

7. Write timestamp to Record_Block

8. Set Data Pointer to end of timestamp

9. Find first data element in record

10. If data type is 'subcategory', proceed to Step 13

11. Append item data to Record_Block

12. Set Data Pointer to end of item data

13. Find next data element in record

14. If there is a next data element, loop to Step 10

15. Write Record_Block to data tag using Current_Tag_ID

16. If Use_Hard_Lock, permanently lock all blocks used; otherwise, set lock bits.

Item Sizes

The four data types which will be written to the transaction record are described following - see also Data Structures.doc - with notes on how the data entry is constructed.

A list data entry consists of the 7-bit field identifier followed by n-bits recording the index value in the list. field identifier (7-bits) | list index (n-bits)

This value n is stored in the Bit Size field for the list entry description.

A numerical data entry consists of the 7-bit field identifier followed by n-bits recording the integer value and 3 -bits containing the decimal offset.

Field identifier (7-bits) | integer value (n-bits) | decimal (3-bits)

This value n is stored in the Bit Size field for the numeric entry description.

A string data entry consists of the 7-bit field identifier followed by a 7-bit value identifying the size - in 5-bit characters - of the encoded string (see Modified EBCDIC String Storage) and then the encoded string itself.

Field identifier (7-bits) | size in chars (7-bits) | string (size * 6-bits)

The string is actually read (decoded) as 5-bit characters but, since the modified EBCDIC character set includes characters to shift between subsets, the average value required to encode a string is estimated to average 5.5- to 6-bits/character. The size recorded will be the actual size in characters

For example, assume a 16-character (original) string is encoded using 18 characters or 90-bits of data. Thus the size recorded is 18 for the encoded size, not 16 for the original. While the maximum string length supported (raw) is 64 characters (requiring 6 bits for the size), the encoded string may be longer (in characters) than the raw string. Therefore, a 7-bit field size is used to specify the string length.

Date Entry

The project database defines a date field description as:

Category ED (index) short, 1..127

Date unsigned long recorded as days since Jan 1, 2000 (14-bits)

Description BLOB (string) optional, may contain a field description, no set length

The date range supported is 1/1/2000 through 1/1/2044.

A numerical data entry consists of the 7-bit field identifier followed by 14-bits recording the days elapsed since January 1, 2000. field identifier (7-bits) | days (14 bits)

Inadequate Space

Before writing anything to the data chip, the process of creating a record begins by building the record in memory as a binary block and testing the block to ensure that the record will fit on the tag or, if not, adjusting the record to fit. If there is not adequate space:

Single Tag:

For a single tag, issue a warning:

There is insufficient space available to record this transaction. You must either add a new tag to record this transaction or edit the information to create a smaller record. Options are required to:

□ Add a new data tag - see Expanding a Tag Set - and continue treating as a Multi-tag Set, following α Cancel the entry Multi-tag Set:

In a multi-tag set, if there is insufficient space on the current tag and there is no subsequent tag available, treat as a single tag with insufficient space, including marking any new tag(s) as added tags since these are not recorded in the original tag set.

Claims

WHAT IS CLAIMED IS:

1. A distributed database system for tracking historical information about an entity, the distributed database system comprising: a processing system that includes data rules for processing received data; a data tag associated with the entity, the data tag storing historical data regarding the entity, the historical data stored on the data tag as variable field length encoded data in a plurality of data fields; and a communication system for transferring the variable field length encoded data between the processing system and the data tag, the processing system receiving the variable field length encoded data from the data tag and decoding the data to retrieve the historical data encoded on the data tag.

2. The database system of Claim 1, wherein the processing system revises the historical data and encodes the revised historical data into variable field length encoded data that is transferred to the data tag on the entity.

3. The database system of Claim 1, wherein the data in at least one of the plurality of data fields determines a field length of at least one other of the plurality of data fields.

4. The database system of Claim 1, wherein the entity comprises an animal, and wherein the data tag is attached to the animal, the data tag comprising a storage device for storing the variable field length encoded data and a transceiver coupled to the storage device.

5. The database system of Claim 4, wherein the communication system includes a transceiver that communicates with the transceiver of the data tag to transfer historical data between the data tag and the processing system.

6. The database system of Claim 1, wherein the entity is a product.

7. The database system of Claim 6, wherein the product is one of a plurality of products, each product in the plurality of products having a respective data tag so that each product can be distinguished by historical data stored on the respective data tag of the product.

8. A method of tracking historical information about an entity, the method comprising: storing the historical information as variable field length encoded data on a data tag associated with the entity; reading the variable field length encoded data and decoding the variable field length encoded data to reproduce the historical data; updating the historical data to include additional information about the entity; and storing the updated historical data as variable field length encoded data on the data tag associated with the entity.

9. The method of Claim 8, further comprising converting the variable field length encoded data on the tag to a fixed form representation of the historical information for permanent association with at least a portion of the entity.

10. The method Claim 9, wherein the entity comprises a cow and wherein portion of the entity comprises a beef product of the cow.

11. The method of Claim 9, wherein the fixed form representation of the historical information comprises a label having visible indicia.

12. The method of Claim 11, wherein the visible indicia comprises a bar code.

13. The method of Claim 11, wherein the visible indicia comprises a two- dimensional bar code.