WO2002101593A2 - 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 mvention 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 mvention; 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 LU and Palm IV, 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 mvention, 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, hi 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, hi 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, hi 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, hi 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 Fire Wire, 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] h one embodiment of the mvention, 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, i 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. 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] i 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 10²⁰. [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. hi 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, h 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, hi 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 0'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 0s 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. hi 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 mvention 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. APPENDTX

Modified EBCDIC String Storage

The EBCDIC (Extended Binary Coded Decimal Interchange Code) character set originated on early IBM systems and was used on some electronic printers. Characterized by a 5-bit character code with a single switch code (cornrnonjy 1 11 1 lb), EBCDIC existed in several mutually-incompatible versions.

Using standard ASCII codes - while convenient — has the drawback of requiring 7-bϊ?s per character (minimaj) to represent data with the first 32 bit codes (00. 1 F) reserved as control characters inherited from teletype codes

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

Compact Strings

In order to ensure compact strings, a ffdefme statement Hags a lowercase to uppercase conversion The cost of switching back and forth from CAPS to lowercase - for names for example, where the first letter is capitalized - Jesuits m a signi icantly liigfier-bit per- character cosls (on the order of 6 5 to 7 bιls/char_versus 5 to 5 2 bus char for 'caseless' text)

Field Delimiters

One new provision has been added to this design, the inclusion of a field delimiter flag (identified as eot^~or gnd <?f field) The field delimiter flag, allows multiple strings to be concatenated in a single stnng field using, the eg Tlag as a separator between strings The advantage is simple rather than identifying separate fields for strings, a single concatenated field uses less space than separate fields

Three-field delimiters are recognized as 'V (CR), '\t' (tab) and T while the ^*\rt" (newline) character - which commonly appears as the pair 'VW - is ignored

Note a change is required because the two alpha character sets do not have space to accommodate an w Tjag Overall, this approach adds minimal overhead requirejnents for stnng storage

separate fields or as multi-line text, conv ersion to ihe final format is left to the end application 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 most 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 set 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 the 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 are 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 which are not otherwise provided — as well as three currency symbols. This also provides seven blank char vafoes which are not assigned but which could, optionally, be used for other international characters.

Here character value 29 shifts back to the first char set while char values 30 and 31 select the second and third char sets respectively. o e that the vertical bar (I) character, previously given the value 14, has been removed from the character set since it is now one of the possible (accepted^{^}) delimiters All subsequent 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 simple expedient of using ihe seven presently unassϊgned characters in Char Set 4 as selectors. Thus two five- bit character entries ^sυch as 19b, 12h through 19b, J 9h ___ ould shift the entire string to an alternate character set.

Benefits

TT __ J c t_ι_* ~ι _{* * Λ}„._* TJ,, «. — — _ΛΛr,. character - an improvement over 7-bit ASCII of 78 to 86%. This is based on the assumption that a shift character will be needed, on average, every 10* character and no more often than every 5 character. λYhiJe not ideal, this does extend the available storage capacity by a factor of 17 to 27%. Unfortuna ely, we'll need to plan this on a 'worst case' basis (17%) although the 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- have shown hit/char averages on the ojder of 5.0 to 5.2 (including field delimiters). Alternatives

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

Implementation

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

Condensed String Characteristics

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

This makes n the smallest number of bits which can express the defined length J with a s character ratio. The actual value stored in the first n bits, however, will be the number of 5- bit characters in the condensed siring and the actual encoded string length — in bits— will be «-bjts plus the value n * 5.

Condensing a String

Condensing a string begins by setting the active character set to the first (default) character set 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 seqvences A..Z, a..z and 0..9,for compression efficiency, the characters in the char sets do hot 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 he conveniently handled in a simpler manner.

Likewise, regardless of the char set, a value of 0 is a space, 27 is a period and 28 is a comma. These would be handled both on expansion and condensing without bothering m^'fh 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- bit value.

AHerDateJy, if the character is found in the 2^nd, 3^ld or 4^Λ char sets, the shift character from the first char set becomes the first five- bit value, followed by the character value while the selected char set becomes the new active char set.

Subsequent if/, then next character from the ASCII string is located, oeginning with the active 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 - in five-bit characters — of the compressed string is determined.

Using the formula preceding, the estimated compression length is calculated to determine the bit size required for the length field before tbe actual compressed length is copied to the bit 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 String Characteristics to determine the bit size of tbe field containing tbe condensed size information.

Wϋb the calculated bit size, the first n bits are converted to an integer c and then the following 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_, tbe condensed siring are read.

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

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

SmartWare™ Data Tags

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

Conventionally, a daiabase- as implemented on systems throughout the world virtually since the invention of the computer and as typified by all systems since pυnchcards were first used to enumerate the US census — contains both data and schema - the latter being the rules for deciphering the actual data — in a single physical location; i.e., a computer and its associated storage mechanisms.

In the distributed database implemented though IDComm's SmartWare™ technology, a distind departure from the conventional is made by placing the data proper in many individual and uniquely distributed sites while tbe database schema— tbe data rules and references for 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 a 'row' of data while individual fields within each record are identified as 'columns' — a terminology which derives most recently from visual spreadsheets (a specialized form of database) and historically from printed ledgers.

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

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

In addition, using the SmartWare™ data storage algorithms, individual data elements are stored in space-roinirnal formats as dictated by defined data ranges for fields and other structural requirements defined by the SmartWare™ system in response to industry or application- specific needs. This is contrasted to industry conventions where 'standard' formats (and sizes) always appear as multiple- bytes (muMph S- bit sizes) following practices originally dictated by CPU- inherent memory addressing conveniences but since adhered to simply for the convenience of established practice and standardized references as embodied by contemporary 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. Statement of Work Hand Held Tag Reader

• Overview for handheld

Tbe Hand Held Reader/writer is designed to read and write digital information to "Tags" (storage units) in a variety of environments anywhere from the jungles of South America 1o the Icelandic plains and from inside buildings lo the beat of deserts. Tbe device is intended to satisfy a myriad of industries in a myriad of environments. The Reader/writer Housing should be as rugged as possible to protect tbe digital electronic components, contained within, that are used to interface with Ihe storage units. Tbe Reader/writer is battery powered and will need all Ibe usual indicators ap charging system to satisfy both US, Asian, European and South Amer jean power systems. Tbe computing device, also contained within, must operate OD the OS platform. Jt is our indent to offer the best on-board computer for ibe particular job that is to be done. The on-board computer must be protected by a membrane of some type to give tbe unit as much protection from the elements as possible.

Mechanical design • Material

Case arid handle

Membrane for OS based unit to seal out environment

Connections for battery charging

Antenna for RF LAN

Antenna for tbe transceiver

Exlensϊon mechanism for Antenna

Thumb trigger for the Transceiver

Environmental conditions

Design layout

Case and han le

Membrane for OS based unit to seal out environment

Connections for battery charging

Antenna for RF LAN

Antenna for tbe 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 tbe RS232 and tbe OS device and the Network OS Device ounting Battery and charging system Charge connector for the OS device Environmental conditions

Testing

FCC Part I5, VDE, CSA

Humidity

Shock aoά vibraiion

Operating Temperature Range

Battery Life and charge time

Overview for hapdbeld

Tbe unit to be designed is a hand held device that wilt be capable of working under adverse condilions- The temperature range of usage is from -10°C to +55"C. The unit will be produced out of a rugged plastic capable of meelϊng various environroeolal conditions and tbe screen cover will be produced out of vinyl or membrane type material that will add to Ibe unit's water resistance capabilities. This unit will house a variety of different components and will need lo be opened and closed at different intervals to allow for updates and maintenance.

Changes lo Ihe SOW

Any deviation from this statement of work, SOW, must be subm ϊftεd in writing. The change request should include as a minimum the following:

• Type of change

• Reason for change

» Cost impacts lo the assembly process

» Cost justifications to the change

» Implementation and design impacts

After submission lo VJDCom^'m, IDC for approval or disapproval, a response wilt be in writing and signed by a company officer.

Mechanical desieu Tor Ibe Bousing

Material

Case and handle; The Case and handle are to be designed and constructed of ΛBS or polystyrene material. Foaming or increasing 1ZOD is acceptable for environmental reasons. If the design engineer determines Ihe need to utilize a different material, it is up to the Engineer to request the change in writing. It must be written in such a way to describe the type of material request and the reason for the change. The material selection must withstand organic or industrial oils, citric acids, UV and salts or sodium

Membrane for OS on-board computer to seal out environment: This is a thin Vinyl sheet or flexible membrane that must be sealed to Ibe handle, by heat or, other process. This wilt allow the touch screen of ihe Palm style unit to he utilized without any extra effort. Must withstand organic oτ industrial oils, citric acids, U and satis or sodium.

Oo-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 lo and must resist oils from industrial or organic, citric acids, UV and sails or sodium, ii vvυuϊu uc »ιϊ».c »o «;»Sϊz e sarrjc materials that are used on remotes for TV's. This material has a good track record.

Components 3D systems

Battery ami Charger for tbe RF Units:

1. The battery should be Nickel Hydride or Lithium, and should be 10 lo I2VDC 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 lo 130V AC. The AC tbargεr can be external with ihe same plug for the DC input. The charge time should be 1 to 2 hours.

2- LED lights will show charging aD charged. A mullϊ color LED may be used.

3. Tbe Batteries should be accessible for changing out when required. Pressure connections or non-soldered connections would be preferable over soldered connections. Off the sbelf style batteries would be preferable over custom ones if possible.

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

Battery and Charger PBIDB Style Units:

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

2. LED lights will show charging, and charged- A multϊ color LED may be used.

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

4. A Ferrϊle core may be required to keep unwanted RF from conducting down the power line. FO VDE, CSA an FCC.

RF Tag Transceiver:

J. ^• There are two different sources for a finished Transceiver board if it is decided that IDComm, Inc. should not to build one. AWJD has a L5"x3"x0.75" device. The other is TRJSYS has a 3"x5"x0.5" device.

• AWID

• 382 Route 59, Section 292

• Monsey, NY 10952

• Contact: Donny Lee, President

• 914-369-8800

• TRJSYS, IDC.

• 21608 N. 20'^b Ave

• Pboenϊx, AZ 85027

• Contact: Mike Drews, Project Manager

• 623-581-74)4 exl. 105

2. Microchip has a parts list with layout instructions.

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

4. Jt would be advantages to read both the Philips I-Code device and tbe Microchip 450 and 355 devices.

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

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

RF Transceiver for tbe LAN Device:

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

2. The option lo choose anolber vendor requires IDComm approval.

3. LAN Based unit will be a separate SOW.

• AeroComm, Inc. J3256 W. 98"' Street Lεne a, S 66215

• Contact: Mike Hufton, OEM Sales Account Manager 800-492-2320 ext. 213 Connection to and Jroro the Hand Held:

Mode) TJOCJOOI

Model TJJC300J

Mode} TDC5001

Antennas

"i . The Transceiver anteDna is lo be mounted into the P7astic shell as show in Figure ?; )f Ihe antenna can not be mounted change drawings mus! be appjovεd. The coirøections to tbe antenna can be either spring contact or flex cable with connectoj plugs. Either way ibe antenna housing will be buiJl -with breakaway considerations. ]f dropped tbe antenna can break off and with minima) effort be re- attached. Tbe antenna is on a slide to allow the antenna to woik outside of the Transceiver -unit. This will help prevent intjarnodujation of data onto tbe processing unit.

2. The LAN Transceiver could be accomplished two ways.

2.1 Aeio Corom unit P LR24O0S wϋb ihe antenDa built into tbe PCB. This will make the handheld more dϊiectional but will he less mechanism and no external antenna lo get damaged or bjoken.

2.2 Aeio Corom unit LX2400 or PXLR2400; without the PCB antenna which will lequirc cable and antenna to be added to the case and PCB. This will add better range and also will be non-dϊrectionaJ. Better solution more material aD cost and w ll be Susceptible to damage. Figuje TJ shows the requested layout.

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

Talm I OS Style on-board compυttr Mounting

L The Communication device is OS based and will be OEM or off the shelf units. Mechanical connection lo ibe unit's RS232 port is requited. Compression would be a gieat way to hold ihe off tbe shelf unit in place and maybe the OEM unil. This compression will come from 1be handle cover compiεssing the unit into ihe base unit. Tbe connectoj roust be able.to connect 1he RS232 and Ihe Charging power foj tbe OS processing unil. A universal connector would be nice. )f needed, a clamp mechanism may be utilized to bold the unit to Ibe Base.

RS232 wiring ϊ. Tbε Connection diagram from above demonstrates how the different models wjj) be ϊied. Tbe RS232 connector for tbe LAN, via USB port should be al tbe rear of tbe handheld for the ability to attach to a single box for charging and communication. Allhotigb this is a foroje option or incorporation, consideration Deeds to be taken on lhis go around.- Jnternal wirag wiH be placed in socb a jnaDner to prevent internal RF problems and to minimize cross modulation and capacitance problems. Environmental issues should be taken with ihe USB port by using a cover br something Jjke il. A cover with a plastic strap that is compressed duiing the assembly process would also be bejpf ϊ. This way tbe cover can be replaced after finishing a connection. Feπite may be required to prevent unwanieo Γ irojn conouowjg out ι»c UJU pυ_>« Auu >au>aιij>g. t on is > > v-^ , »vι, and FCC rules.

PCB Mounting

All PCB's will be mounted by snap in style connection as a primary request. The use of screws woujd be a Jast resort. )1 wij) be up lo Ibe design engineer to come up with ibe easiest solution to tbe mounting issue. There will be cusloroeis thai buy an TDCJ00J and want to upgrade to an JDC300J handheld. We would like for them to just plug and play. Jt would be optimum for fhePCB's to be jernove as easily as il was installed Case, Cover and Antenna mechanics

1. Figure 111 is ihe proposed assembly jequest. A different one can be used with written authorization. J.2 The handle wiJJ snap into place wilh a ball end type binge. The ball hinge can be accomplished also by any other means. IDComm prefeis this style hinge. The handle of the cover will be sciewed into place with special star type sciews. This will protect companies from having employees tamper with tbe handheld unit and also wi)l help prevent the theft of Ibe PaJro style units. 3f a Dap in style weie cjeated it would be nice to have a special lool to unsiiap the handle from tbe base. Tbe handle must be designed to give maximum sliεngtb wilh minimum weight and bulkiness. The finished unit must wilhsland a 4-foot djop test.

J .2.2 Thε Membranε should be a separate weatherproof snap in. This component will have a Jajge ware factor and will neεd lo be replaced every so often. If this ca_Dnot be accomplished than the membrane can be heat- sealed to the handle ar d tbe handle wiJI need to be replaced. This will cause piobJems for Ihe customer, in having lo remove it coropJetεJy from the base unil and also causes problems with the buHon. } .2.3 The Button will be attached to tbe switch and should be mounted in a wa ibat replacement of tbε enliiε unit can bε accomplished at the customer JeveJ. This button should be engineered to fil wilh off tbe shεlf coroponεpts. J.3 The Base unit wi)J have the necessary area lo mount all requijed components ajyό PCB's. The base should be designed with lounded sculptured looks and should not veiy loo much from the concept drawing.

Tbe base UDΪI roust allow Ibe antenna to become dislodged fjeejy when dropped. Tbis js lo minimize tbe damage lo both parts. Tbε slide mechanism should be designed in a manner to allow the anlεnna to be snapped back into place alter being dislodged. The slide mechanism should also allow for maximum extension without allowing the antenna to be extεndεd past tbe end of lie base. J.4 Thε antenna housing sboujd have the wire antenna molded into it. This is ihe preference. Other alternatives wifl be eligible for jevϊew. The antenna housing will contain tbe antenna and tbe connections from the anlεnna lo the base. F Jεx or ribbon cable is one way of connection. Spjing mounted pins rosy be another styJe of connection.

EnvjroBiDCBta) Conditions and Rto/ujreπients

The unit wiJJ pβss a variety of tests without failuje to the operation of Ihe handheld. iΛx>p j esi nom i-ieei on two corners ana nanoie. j ne antenna cioseα ana extended.

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

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

Moisture Resistance pei MIL-STD-202 method )06 except the temperature wil) be 40°C aDd thε relative humidity is to be 90%. Test duration to be JOOhrs.

Temperature extremes from - J0°C !o-ι-55⁰C in operational mode.

Life test JOObrs at -»55°C in operation condition.

ESD at J5KV 3 limes in, J 0 sec. 30J V one lime. Must remain operational. Electronic Conditions and KeqmrtTDcnts

Radiated susceptibility at 5CV/n» 5MHz lo3GHz_ Tbis 5s to be done oo ibe

TJDC5001.

Conducted susceptibility MIL-STEM 63 B

FCC rules and regulations for part 15

CSA

VTΛE

FIGURE 1

FIGURE TJ

FJGURE DJ languages) are stored as 32-bit (8 byte) entries. Date and lime 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 modified BAUDOT) coding where tbe resulting encoded strings cornmonly require 5 to 5.3 bits/character. This is contrasted by conventional strings which have a fixed size of 8 bits per character for ASCII or 16 bits per character for UNICODE format. While no explicit provisions have been made as yet to support multiple languages (per the International UNICODE format), the Smart Watre™ lext format can be extended for international support by using font pages for non- European character sets.

Specialty data types can be created as required foτ custom applications, again following the practice of storing data in minimal space configurations rather than relying on standard (and wasteful) data structures.

Data Security

► Data can be uniquely encoded and decoded in a highly secure form without being vulnerable to 'cracking' or decryption without the encryption key. This feature is possible because of the nature of the compressed data structure where any 'key' can, potentially, return an apparently 'meaningful' decode without actually restoring the 'real^" data. I.e., without the specific and correct key, once data has been encrypted, 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 for encrypt ion/decrypt ion.

Summary:

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

Because the media (RFID tags) used to store the distributed data have limited capacities, the packed data- format algorithms discussed provide the means of rendering tbe theoretical processes as a practical implementation. While tbe details of how packed data formats are implemented can vary, the principal of storing data in minimal (bit-size) formats defined by an external schema is uniquely different from the data storage practices used throughout the computer industry. • Public data can be readily accessed at remote or distributed locations

• Private data can be encrypled for protection.

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

Elements comprising SmartWare™ Data Storage

• pst'g elements are stored in a referential format such that the 'bits' of information appr sing the data reference are the minimal size possible according to the :*π:røples of Information Theory. The result of employing such variable data sizes ni uces a distinct savings in storage capacity in circumstances where 'data space' is limited and usage is at a premium. o Selections from lists are stored as list indexes where tbe size of tbe individual entries are determined by the size of Ibe total list rather than (per conventional usage) being stored as values using 'standard' data sizes. I.e., rather than using a BYTE (8-bit), WORD (16-bit) or DWORD (32- bit) value to store an index, for a list containing ten entries, tbε 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. o Numerical values — both integers and floating point values — are stored in a minimum significant digits format. nteger values are stored simply as integers using the smallest bit-size required by the defined value range with negative integers indicated by a flag bit (a two-entry fist) where permitted by the record definition. Floating-point (decimal fraction) values are also stored as integers (same rules) with the record schema providing a conversion from the stored simple integer to tbe original decimal value. Advantages are:

^» a single compact format for both integers and fJoating-poΪDt values,

* minimal storage requirements dictated by the maximum allowed value.

In this form, an integer with an allowed range 0..100 requires 7 bits storage hile a field with a integer range 0..25 is stored using only 5 brts. ConverseJy, a standard integer value is normally 32-bits covering the predefined range: -2147483647 to 2147483647.

Jn like fashion, a floating-point value such as 123.4 (with a perrnitted range of 0..999.99) would be stored as 12340 (requiring 17- bits). Conversely, standard floating-point entries are stored as a 64-bit (8 byte) values suitable for the fixed-range -0.9999999999E+1 to 0.9999999999E+20. o In the standard SmartWare™ implementation, dales and times are stored, respectively, in 12-bit and 1-bil formats; the first being defined as days elapsed since a root date and the second as minutes since midnight. Conventional date and date/lime values (using Microsoft's programming Overview

To develop a genejϊc software called SroartWaje™ thai is windows based, (Unix is an option), for companies in need of external as well as internal trackin of information on devices, systems or services. This softwaje is designed for M)S departments and wi)l be used lo build tbe required field information base, which is converted into data, files for leading and writing lo RF Tags wilh memory called 3E")!)™. Then to enable Ibis data file and the accompanying SroartWaje ^7>* to be uploaded via multiple ways into Hand Held RF data collection systems that will be used by employees when yiling and leading to Ibe SD'ID™ devices. Tbe information can be written lo each 3D^»rD™ unil that is carrying tbe H> requirements of ibe company-coded system. This will allow multiple KF Tagging devices to be in Ibe same vicinity as tbe 3D»T0™ devices and nol breach security and miss wiiles. Tbe goal is to allow firms to place 1 OOlbs of information into a lib ox. Tbeje is approximately 600 lo 1250 bits of storage capable on the 3D-TD™ devices. Tbis converts to 30 to 60 words of storage. The software to be developed, SmartWare™ will do Ibe data δeld compression allowing multiple words and statements to be placed through Ibis compression onto the 3D^»ID™ devices. Tbe units that will carry Ibe Data files will vaiy in memory fioro 2Megs lo ϋMegs.

Our J^irbe Industry Market Types

Shipping Bill of Lading

Shipping for Tracking information

Customs

Pallet Tracking

Service and Maintenance systems

ISO 9000 service and preven!3tϊve maintenance

Custom assembly systems

MRP systems

Rental company damage tracking

Livestock Identification tracking

Types of PC Based Systems

> DOS

• Windows (3.1), 95,08,2000 and NT » Linux

Unix

Types of Hand Held Protocol

^•V » Windows CE, Casio

Types of Bapd Betd Communications

. RS232

- 900MHz SS @J.6M/s

• 2.45GHz SS @1.6M/s

^» RF Internet interface (Palm VB)

Typrs of RF Tag Protocols

- Philips, ] Code™

» MicioJD™

• Mιcro450

• Taglt™

• Peiforma⁷**

PC Based developer software, martWa e™

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

» Moniloi bow much memory the data files are tak g up

» Helps JS υndπstand that theje will be olber firms wjtb band held jeadejs with jnuliiple company data hies w them and that wasting memory is not a good idea

• Tag memory level indicator

» A roust for the amount of stimged bits being attached to each category during development of data files » Bit system help for categories

* This is to allow tbe developer to utilize each category size economically and lo allow for j tuie size cjeases

• Special jυnclion cells

» These cells which will write ASCII to the chip when jequned and ajε for very special instances where there is no way to data table the entry, i e customs clearance number ► Revision cell

- This is Special cell that allows tbe older genejation tags to be read wilh newer generation Data

Altjibute dictionary building and field linking

These field modifiers allow various functions to occur dujmg development These will cause Ibe fields to become relational and add Oexibility lo dimension to the data being developed

Tag Memory

The tag has read wrile EE prom based memory and vanes from 800 Bits of storage to 1000 Bits of storage Tbe Mιcro450 has ibe capability of being flagged as non erasable which locks tbe memory information permanently We would like lo utilize Ibis under certain conditions

' Software to be able to Hag portions of memory as non ejasable » Software to be able to flag all memory as non erasable

» Need a fuel cell to be visible on the band held menu for amount of memory left and to alarm if write is going to exceed the memory available The software will have a wizard to help tbe MIS department create tbe required fields and attributes » * "NOTE Thε Wizard needs to keep MIS informed as to how much environment tbe data fields aje lakmg up It should include a bit field table to show tbe different types of sizes as shown jn below

Attributes lo Fields

• The attribute is an extension to the held, which has multiple characteristics. Theje should he at least 10 attiibutes pel field.

» Some of these attiibutes will tie other fields logeihej. ' Some of them may tie ibe fields to one or multiple categoiies » Some may evoke a subroutine oτ do loop or look up table The attribute should be a library tbat is built by MIS and can also have examples with tbe wizard.

REVIEW - .^

The soStwajε is designed to jead and write to a JOOO bit RF Tag. The written data is ϊnfoπnalion pertinent to the company. The data being read can be ASCII formatted and transmitted to LAN systems for further processing. Tbis is accomplished through RS232, RF 900MHz, RF 2.54GHz or Internet access via the palm pilot. The software data is what the user creates and is done through a number of steps and queslions. These questions cieate Tag styles and categoiies along with special fields for ASCTJ and revision formats.

The software data filers) are intended to be designed and buill by MJS al the start in a PC based system. After the Data file has been coropJeled by MJS, our software writes tbe new data file and the SmartWare ™ to the Hand beld ihrougb Ihe RS232 interface or RF link. This data file, which is a * .dal formal, can be e-mailed to any location requiring tbe 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 pBlro and KF reader has SmartWare ^,M. Readers may lequire up to500 *.dat files for reading incoming tags. We can allow the RF baDd held units to transfer the lequϊied data files as needed to save roeroory.

Tbe soflwaje is Field driven wilh each cell carrying its own identifier and will have link att^jibules allowing multiple options.

39

AH programming will be documented fiom algorithms to code. Good programmiog practices will be utilized on all levels of development.

Strategy

1. Develop a worlάng model on the board or paper and prove out the spreadsheet theory.

2. Develop 3 workiog model on the PC for review and comment and ^'refinement

3. Take worfctsg mode} and prodace a simple demo for marketing. .

4. Start developing the Wizard and help functions

5. Dr run wilh real systems

6. Debug and rerun if required

7. Start She application review process.

Reading Tag Data

These instructions for reading data tags apply to both desktop and Palm-top applic3lions.

Tbese piograro sequences detailed following are diagrammed as a bubble chart (Yϊsio 2000) in tbe 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 TJWORD vahies) rising the structure described here and in the Data Structures document:

Field Bits BH FI elds Block Items Notes

Name 96 0 . 95 3 7 92282E÷28 Requires three 32-bit blocXs

Hardware Version Jt 8 0 7 1 256 Hardware version (nominally 1)

Company 20 8 27 1 1,048,575 Company identifiej (assigned by ID Comm)

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

Major

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

Minor

Program ID # 14 42 . 55 2 65,538 Piogram løertrnei (created by program υlilfty)

Piograro Revision # 8 56 63 2 256 Revision number (created by piogram utility)

Expiration flag 54 65 4 expiration flag.

0 = NO_EXPIRE

1 = COUNT_EXP)RE

2= DATE_EXP!RE

Court oi Dale 22 66 87 4.194,304 expiration count or date Date/time Formal 3 88 . SO 8 DateΛime loπrrat identifier

0 = no daleΛime slamp

1 = dale only

2 = dale / hour only

3 = dale I hour I minυlε

4 = date / hour / minute / second

Wsζ_Hard_loclι 1 91 1 T ; F Default = FALSE

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

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

1 = single wrtfi adds, 2= tirsl lag in set 3 = teg in sequence, 4 = added tag

The Date Stamp is the Zufu dale (GMT) expressed as days since 1/1/00— i.e., a value of 0 woul 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, tbis format wiB be supplanted in later versions with a Jess restricted size. Tbe 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 thε Date/Time Format specified, this initial Time Stamp is always written in minutes since midnight GMT.

If a multiple fag set is being created— i.e, if the Tag YJse Count field from tbe 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 tbe 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 TagJUse Flag is Multiple, proceed with tbe Read Tags operation; if Single Packed, proceed with Read Single.

Read Tags (Reading a Tag Set)

The first action in reading a (ag set is to identify tbe fags comprising ihe set. . 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, Nest Tag ID (block 4) and Previous Tag ID

(block 5).

Note: the first tag in the set (Multiple Tags = 1 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.

. r «-» _ _ .. . i.

:_ _r — * .: — » _* — m is- * - i t ».~ » if. eaicjj tjj χ>uιg ιag», jjuctj_'.u.ig uy ι«g J L». JI αu_jr wgj ω wuuu, _>wy IU i j.

7- If referenced lags cannot be found, issue a warning and log the lags 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 ϊn the set. reading blocks 5..32. If the first tag is missing, begin ^' with Step 4. 2. Append tbe data to Record Block

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

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

5. Append data to Record Block,

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

7. Loop to Step 3. Prepare Data Record . 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 tbe data records are in a memory block (Recørd_B!ock) the retrieved information can be parsed into individual transaction records.

1. Begin by setting Block Ofisεt Record Oflset, Item Count and Pield Coυnt as zero.

2. Beginning at the Record Oflset, read the Report ID from the first seven bits; increment Block Oflset and Record Oflset.

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

4. Check Record Oflset. If tbis is not the last tag, increment Record Oflset to tbe 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 tbe program data. % If Date/Time Format = 0, proceed to Step 12

8. Read the timestamp from Record Block; tbe size of the timestarop is determined by the timestamp format in the program data structure.

9. Are all bits in the timestamp 1 s? 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 Ibe Report ID and timestamp retrieved from tbe Record Block.

1 1. Increment Block Offset and Record Offset. ^" 12. Read ihe 7-bit Field Co uBt from tbe Record Block; increment Block Oflset and Record Oflset.

13. Read Ihe 7-bit field ID from the Record Block; increment Block Oflset and Record Offset.

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

15. Reed the field data from the Record Block; increment Block Oflset and Record Oflset; increment Item Count.

16. Convert raw data per field data requirements

17. If Item Count is less than Fiεld Counf, loop lo Step 13.

1 8. At tbe end of thε transaction, if Record Oflset is not at the first of a 32-bit boundary, increment to 32-bit boundary.

1 . Set Block Oflset, Item Count, Field Courjt 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

1 . If next data element, loop to Step 9

1 1. Done, return

Writing Tag Data

These instructions for writing data tags apply to both desktop and Palm-top appHcations.

These program sequences detailed foDowing are diagrammed as a bubble chart (^"Visio 2000) in the Write Tag Data.vsd file or as a set of images in ^"Write Tag Data.zip.

Initiafiziπg 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 BHs Bits Bit Fields Block Items Holes

Tola⁾ 96 0 .. 95 3 7.32282E+28 Requires three 32- bit blocks

Hardware Version 3 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 it 7 28 .. 34 1 /2 128 ID Comm major version ID Majo)

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

Piogiam 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 2 64 .. 65 3 4 expiration nag,

0 = NO EXPIRE

1 = COUNT EXPIRE

2 = DATEJΞXPIRE

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

Date Time Format 3 88 .. 90 3 8 DateΛime formal identifier

0 = no date/time stamp

1 = date only

2 = date / hour only

3 = date / hour / minute

4 = date / hour / minute / second

Use Haid lock 1 91 1 7 / F Default = FALSE

Usage and Access 92 0 = !N_HOUSE. 1 = EXPORT Multiple Tags 93 - 95 0 = single tag, no adds, packed record

1 = εϊngte 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 tbe individual values supphed by the database will be integers or short integers, these values must be reduced to tbe Least Significant Bits - not bytes - per the design specification and then packed to create tbe 96-bit data structure.

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

Tag Data Header

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

2. Retrieve Hardware Version fiom registry, format as 8-bit value, write lo bits 0..7 ! HKEΪ_XOCAl,_MΛCHlt E\SOFTWARE\3 DCoπιm3 "Hardware Version"

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

ID] "Company ID"

4. Retrieve IDComm Major Version if from registry, format as 7-bit value, write to bits 28.-34. [HKEY_l,OCΛT_J_MACH3NE\SOFTWARE\1DCoιr!im3 "Major Version"

5. Retrieve IDComm Minor Version # from registry, format as 7-bit value, write to bifs 35..4 L | HKEY_l,0CAl,_MACH3NE\S0F ARE\3DCojπm] "Minor Version"

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

7. Retrieve project_or evision # from program schema file, format as 8-bit value, write to bits 56..63.

8. Retrieve the Expiration Flag value from registry.

IHKEY_LOCAT_J_MACH3»E\SOFTV3AREMDComm) "Expiration Code"

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

10. Retrieve tbe Expiration Count value from the registry.

IHKEy_LOCAX._MACHINE\SOF «RE\3DCojnm} "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_EXPΓTE (l)

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

2. write to bits 66..87. o DATEJΞXPIRE (2)

1. get tbe current date as days since Jan, I, 2000

2. XOR the Expiration Count (from registry) with tbe Company JD

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 timestaπιp_f ormat fsom project schema file, format as 3-bit value, write to bits 88..90. 13. Retrieve use_hard_3 ock Dag from the project schema file, format as a Boolean flag (1-bit), write to bit 91-

Nole: the υse_bard_l ock flag not presently provided - simply "write the flag as FALSE (0)

1 . Retrieve usage_and_access flag from the program schema file, format as Boolean flag (1-bit) where IN BODSE = FALSE (0), EXPORT = TRUE (1), write to bit 92. blote: the υsage and access flag is not presently provided - simply write the flag as IN HOUSE (0).

15. Format 1he tag_nse_coυnt value as a three-bit value, write to bits 93..95, proceed to Initialize Tag.

Initialize Tag

1 Set tag_cotmt tO 1.

2. Write the 3 32-bit header blocks 1o tbe tag

3. If tag_use_coΩnt equals 0 (S ngle Padded), soft lock blocks 1..3, write O's t 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 ag_ιαse_coτa »t is equals 0, write O's to block 4 (Nest Tag ID), do not lock- proceed to Check Tag.

7. If tag_coταnt is greater than or equal to

proceed to Link Tags.

8. Select next data tag. 9- Increment tag_count. 10. Loop lo Step 2.

Link Tags h Select the first tag in set. . If this is the last tag in the set, write O's to hlock 4 (Nest Tag ID), do not lock, proceed to Step 5.

3. Write the Tag ID for tbe next tag in the set to block 4, lock block 4.

4. If this is tbε first tag in tbe 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 JD), do not lock.

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

7. Select the next tag in tbe set, loop to Step 2. 8. Write Tag ID(s) to database along with Program ID, Revision # and flag set as Initialized OnJy.

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 ihis time, the process of initializing the data lag 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 (oτ 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 Ibe Expiration Flag (bits 64..65).

2. If tbe flag is DATEJEXP1RE (2), go to Step 5.

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

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

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

6. 3 D} "Warning Days"

g Days, issue an expiration warning. Proceed to Slep 10.

COVNT_EXPJRE

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 tbe Company ID, unlock block 3, reset the count value in bits 66.-87, relock block 3.

9. Retrieve the Count Warning value. i HKEy_10CAl,_MACH3NE\SOFTWARE\3 DCoτπm\Coιιvpany 3D3 "Warning Days"

If the count value is less than the Count Warning vafue, issue a count expiration warning. j ojεxjpjKE

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

11. If tbe iag 5β_ oιωt equals zero (Single Packed), go to Single Tag.

12. Go to Check Space.

Check Space

The Check Space routines check tbe tag set to determine how much space is available. . 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 tbe 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 ibis 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. ]f so, treat as a Multi-tag Set.

2. Search for free space

3. Set Available Size

4. Set Current Tag ID to the tag 3D- 5? Set est_Tag_lD = 0

6> Set est_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 I to the tag ID.

4. Find Ihe next tag in the set. 5. If the next tag was not found (or damaged, etc), o Set Next Tag ID = 0 o SetNext_Sϊze=0 o Go 1o Create Record

6. Search for free space 7 ?-.f ejtJSϊze

S ^r- :' est TagJLD to tbe tag IDS'. ft eat Tag ID = 0

10 (. heck Nest Size; if 0, then set Next TagJLD = 0 II. 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- . Initialize an empty record block.

2. Set Data Size, Itera Count, Jtems Remain, Data Pointer and Ifem Count Ptrto 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 tbe ReportJLD.

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

5. Set Data Size to the size specified by tbe program's Date/Time Format.

6. If SpBt Record is TRUE, set all bits in tbe timestamp to 1 s. Tbis 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 Jtero Connt Ptr to Data Pointer.

10. Copy ltem Count (7 bits) to Record Block,

11. Set Data Pointer to end of ltem Count. At this point, Itεin Cotint is zero but ibis 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 tbe d3?a tag(s) and the space required to write tbe data record If necessary, tbe data set will be split into two records— on a best-fit basis — with the second record written to tbe next tag in ihe set.

1. Find tbe first data element in tbe set.

2. Set ltenrj_Size to zero.

3. Is 1be 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 Sϊze from tbe Modified EBCDIC subroutine. Otherwise, get ltem_Size from tbe program script. See Item Size, foliowing.

5. Increment ltem_Size by seven (7) for the field identifier size.

6. I fltεrn Size is greater than Available Size, increment Items Rexnaϊn and proceed to Step 12.

7. Decrement Available Size by Jtero Size.

8. Flag the item as Processed.

9. Increment ltem Count.

10. Write the 7-bit field ID to Record Block, set tbe Data Pointer to the end of the field JD.

1 1. Write the item data 1o the Record B lock, set the Data Pointer to the end of tbe 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.

1 . Use ltem Count to overwrite th original ltem Count in the Data Record witb tbe new value.

15. Proceed to Write o Tag

Write to Tag

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

1. Jt ltem Count equals 0, there is no data in the record — Reiurn.

2. If Iterns Remain is zero, continue with Step 4.

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

Following this option, the process of creating the data record and writing ihe tag starts again with tbe Check Space provisions. In this fashion, tbe first half of a 53

split record is not created unless there is reasonable space to write tbe second half (i.e., there is an additional tag available). See Inadequate Space following

4. Write Record Block to tbe data tag (Cnrrent_Tag_ID)

5. If the Use_Hard_Lock flag is set (TRUE), permanent y Jock all blocks used; otherwise set tbe lock bits for each block.

6. If Items Rerjoajn equals zero, Return; lhal's it, all done.

7- Lock any remaining blocks on Current Tag lD. Since tbe 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 CurreDt_TagJLD to Nest Tag.

9- Set Iterns Remain to zero, set First Trausaction to FALSE, set SpliHReeord to TRUE.

10. Return to Create Record to process rem-ύning fields

An Example:

Data is written to a tag beginning with the first empty block following block 4. Tbe first, record written begins with the Record ID value as tbe first 7 bits of the data record, followed by the Field Count (the number ofδelds in the transaction) and then tbe field identifier of tbe first data field. Following the field ID, the field data varies in length according to tbe data type and the program specifications.

Next, following the field data, another 7-bit field ID is followed by tbe corresponding field data and so forth until all fields have been written.

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

Report IP j viroestamp | field cpt [ field ID j field data field IP field dats

-•-■ 7 bits n bits 7 bits ! 7 bits I size vanes 7 bits I size vanes

If a transaction record is too long to fit in the available space, the transaction may be broken and written as two records with tbe 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 tbe new lag, retrieve thε tag D as New Tag lD

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 dala o cancel the transaction

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

5. If this is a singJe t3g, read Last Tag ID from tbe current tag; if a multiple tag set, find the last tag in the set and read Last_Tag_TD.

6. Read the header blocks from the tag identified by Last Tag JD

7. Write New Tag LD to BJock 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 TagJLD, soil lock blocks 1..3

10. Write Last TagJLD to Block 5 on ew agJLD

11. Lock block 5 on New Tag lD

12. Write O's to BJock 4 on ew Tag_ID, do not lock

13. Write O^'s to alJ remaining bJocks, do not lock

14. Exit

Singfe 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 JCD to Record Block

4. Set Data Pointer to end of Report lD

5. If Date Time Format equals 0, proceed to Step 9

O- rujJJΛii tϋJlCM-UΪJp el rάiτJTϊvύt .i-OfTS-it

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 'sυbcategory', 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. f there is a τ<Λ data element, loop to Step 10 15. Write Record Block to data tag using Current_T3g_TJ)

16. If Use Hard Lock. permanently lock all blocks used; otherwise, set lock bits.

Mem Sizes

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

List Entry

A list data entry consists of tbe 7-bϊt field identifier followed by π-bits recording the index value in the list. field identifier (7-bits) j list index (rr-bits)

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

Number Entry

Tbe roject database defines a numeric field description as:

A numerical data entry consists of tbe 7-bϊt field identifier followed by 77- bits recording the integer value and 3-bits containing the decimal offset.

This value n is stored in the Bit Size field for the numeric entry description- String Entry The ro ect database defines a strin field descri tion as:

A string data entry consists of the 7-bϊt field identifier followed by a 7-bϊt value identifying tbe size- in 5-bϊt characters- of the encoded string (see Modified EBCDIC String Storage) and then tbe encoded string itself. field identifier (7-bits) | size in chars (7-bits) j string (size * 6-bits)

The string is actually read (decoded) as 5-bϊt 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-bjts/characteτ. The size recorded will be the actual size m characters

For example, assume a 16- character (original) siring is encoded using 1 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 tbe raw siring. Therefore, a 7- bit field size is used to specify the string length.

Date Entry

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

A numerical data entry consists of the 7-bϊt field identifier followed by 14-bits recording tbe days elapsed since January }, 2000. field identifier (7-bits) days (14 bits)

Inadequate Space

Before writing an>1hing to tbe data chip, the process of creating a record begins by building 1he record in memory as a binary block and testing tbe 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:

TOT 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: o Add a new data tag— see Expanding a Tag Set — and continue treating as a Multi-tag Set, following

D 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 jecorded in the original lag 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.