Source: http://www.google.com/patents/US20070276984?dq=5,973,252
Timestamp: 2015-01-26 07:05:17
Document Index: 689792726

Matched Legal Cases: ['art 1400', 'art 1400', 'art 1400', 'art 1400', 'art 1500', 'art 1500', 'art 1500', 'art 1500', 'art 1700', 'art 1700', 'art 1700', 'art 1700', 'art 1700']

Patent US20070276984 - Data format for efficient encoding and access of multiple data items in RFID ... - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inAdvanced Patent SearchPatentsMethods and systems for optimizing storage of data items in a memory of an radio frequency identification tag (RFID) are provided. The data structure for optimized storage includes a packed object having a length section including an indication of a number of identifiers in the packed object, an identifier...http://www.google.com/patents/US20070276984?utm_source=gb-gplus-sharePatent US20070276984 - Data format for efficient encoding and access of multiple data items in RFID tagsAdvanced Patent SearchPublication numberUS20070276984 A1Publication typeApplicationApplication numberUS 11/806,050Publication dateNov 29, 2007Filing dateMay 29, 2007Priority dateMay 26, 2006Also published asEP2022275A2, EP2022275A4, US7822944, US7849107, US20070276985, WO2007139969A2, WO2007139969A3Publication number11806050, 806050, US 2007/0276984 A1, US 2007/276984 A1, US 20070276984 A1, US 20070276984A1, US 2007276984 A1, US 2007276984A1, US-A1-20070276984, US-A1-2007276984, US2007/0276984A1, US2007/276984A1, US20070276984 A1, US20070276984A1, US2007276984 A1, US2007276984A1InventorsFrederick SchuesslerOriginal AssigneeSymbol Technologies, Inc.Export CitationBiBTeX, EndNote, RefManReferenced by (12), Classifications (9), Legal Events (3) External Links: USPTO, USPTO Assignment, EspacenetData format for efficient encoding and access of multiple data items in RFID tagsUS 20070276984 A1Abstract Methods and systems for optimizing storage of data items in a memory of an radio frequency identification tag (RFID) are provided. The data structure for optimized storage includes a packed object having a length section including an indication of a number of identifiers in the packed object, an identifier section including a directory of indices representing an identifier for each data item contained within the packed object and a data section encoding a data portion associated with each data item included in the data section.
1. A data structure embodied in a tangible computer readable medium for optimizing storage of data items in a memory of a radio frequency identification (RFID) tag, the data structure comprising:
a packed object including:
an identifier section including a directory of indices representing an identifier for each data item contained within the packed object; and
a data section encoding a data portion associated with each data item included in the identifier section.
an external directory, wherein a predefined bit pattern at a predefined memory location indicates the inclusion of an external directory in the data structure. 4. The data structure of claim 1, wherein the data section of the packed object includes a plurality of subsections.
an antenna; control logic; and a memory including a data structure embodied thereon, the data structure comprising:
a central processing unit; and a memory including a data structure embodied thereon, the data structure comprising:
DETAILED DESCRIPTION OF THE INVENTION 1. Exemplary Operating Environment Before describing embodiments of the present invention in detail, it is helpful to describe an example RFID communications environment in which the invention may be implemented. FIG. 1 illustrates an environment 100 where RFID tag readers 104 communicate with an exemplary population 120 of RFID tags 102. As shown in FIG. 1, the population 120 of tags includes seven tags 102 a-102 g. A population 120 may include any number of tags 102.
Modulator/encoder 208 receives interrogation request 210, and is coupled to an input of RF front-end 204. Modulator/encoder 208 encodes interrogation request 210 into a signal format, such as one of pulse-interval encoding (PIE), FMO, or Miller encoding formats, modulates the encoded signal, and outputs the modulated encoded interrogation signal to RF front-end 204.
2. User Memory Bank This section describes an exemplary format definition for a user memory bank 460 in RFID tags (e.g., in ISO 18000-6C tags). The format may be used when encoding user data according to specifications defined by another standards organization (such as EPCglobal). The exemplary format is designed to maintain basic backward compatibility with tags formatted according to a specific standard(s) (e.g., ISO/IEC 15962-formatted tags), but offers increased encoding efficiency. The user memory format and associated encoding and decoding methods described herein are extensible to memories of any size, but bit efficiency may be optimized for memories under 1K bits. Regardless of available memory sizes, air-interface Write and Read times need to be minimized. It is assumed that encoding or decoding time using today's CPUs will be insignificant compared to air-interface time. According to one embodiment of the invention, a solution can utilize a fairly complex encoding and decoding algorithm if it minimizes the number of encoded bits for a given data set that need to be transferred over the air interface.
2.1 Data Storage Format Identifier (DSFID) DSFID 510 includes information related to the organization and encoding of data in user memory bank 460. A variety of techniques could be used with the present invention to indicate the organization and encoding of data in user memory bank 460.
In a second technique, a combination of an abbreviated DSFID 510 and one or more bits from the PC bits of UlI memory bank 480 can be used to indicate the organization and encoding of data. In this technique, the DSFID 510 includes only the access method field. In an embodiment, the access method field is two bits. As in the first technique, one value of the access method bits (e.g., �10� or �11�) may be used to identify that the tag uses packed objects. One or more bits in the PC bits of UII memory bank 480 are used to identify the data system used for packed objects 520 a-n. For example, a default data system could be defined for user memory bank 460. The value of the application format identifier (AFI) bit (e.g., PC bit 17) in UI memory bank 480 can be used to vary the default data system for packed objects 520 a-n. A value of �0� confirms use of the default data system (e.g., AIs) and a value of �1� changes the default to a second data system (e.g., DIs).
2.2 Packed Objects The structure of a packed object 520 explicitly encodes the size (in bytes) of packed object, allowing for speedier sequential access. In addition, the structure provides the option for storing multiple data items, including items from different data systems, within one packed object 520. This storage format minimizes the bit-overhead entailed in encoding each distinct packed object 520, and allows the data content from multiple data elements to be concatenated before compacting, preventing wasted pad bits at the end of each data item. Furthermore, the packed object 520 structure described herein provides a degree of random access, without incurring the bit-overhead of adding a full Directory section as does the ISO Directory method. This is achieved by grouping all the Header ID index values for a given packed object 520 at the front of the packed object 520, creating a �mini-directory� 535 for each packed object 520. Unlike the ISO Directory method, in the packed object format, there is no need to repeat the ID values in two different areas of the tag memory.
2.2.1 Length Section FIG. 6 depicts an exemplary length section 525, according to embodiments of the present invention. Length section 525 includes two length vectors (number of IDs field 626 and object length field 627) and a flag (pad indicator 628). Number of IDs field 626 indicates the number of ID values in the packed object 520. In an embodiment, one is added to the value in the number of IDs field 626 to obtain the total number of ID values. Number of IDs field 626 may be a variable 3-bit extensible bit vector (EBV-3). The EBV-3 is a data structure having an array of one or more 3-bit blocks. Each 3-bit block has an extension bit and 2 data bits. To support a terminating pattern of all zeros (described below), the meanings of a three-bit EBV-3 may be reversed. The use of EBV-3 is a design tradeoff to minimize the overhead of supporting a given feature in a tag that is severely memory limited while supporting that feature, at worse than minimal overhead, in a larger tag that can better �afford� the overhead. In the case of conveying the number of IDs field, the EBV-3 favors small (less than 5 ID) objects that will naturally be found on smaller tags. Very large ID numbers will be inefficiently expressed but will likely occur within relatively large tag memories.
2.2.1.1 Implied Packed Object Length Under certain circumstances portions of length section 525 may be omitted to reduce the number of bits transmitted. When a small number of IDs are encoded (e.g., only one ID encoded), the length of the packed object 520 can be implied from the ID value. For example, if the number of IDs field indicates that only one ID is encoded (e.g., EBV-3 bits are �011�), then the normal ordering of sections within the packed object 520 is changed in order to save bits. In this scenario, the single ID value immediately follows the number of IDs field (e.g., the �011� EBV-3 pattern). Furthermore, if the single ID value indicates one or two all-numeric data items (and thus, no alphanumeric (A/N) subsection is present), then the remainder of a standard the length section 525 is omitted (e.g., the object length field 627 and the pad indicator bit 628 are omitted, thus saving seven bits). If instead the ID value indicates an A/N data item, then the remaining bits of length section 525 are not omitted, and instead immediately follow the ID value. The encoding format proceeds normally from that point. In addition, the ID value or object length field may be followed by a character map length indicator. For example, the character map length indicator may be formatted as EBV-6. The normal data section 560 follows the character map length indicator (which in this case will begin with a standard A/N header). In the case of A/N data, this mechanism only saves one bit (the Pad Present bit), and at the expense of even more complexity when parsing past an �uninteresting� packed object 520.
2.2.1.2 Packed Object End Pattern Eight successive �0� bits at the expected start of a packed object 520 can be used to denote that no more packed objects 520 are present in the remaining bytes of user memory bank 460 or to indicate the end of user data in user memory bank 460. Under normal circumstances, eight successive �0� bits at the expected start of a packed object 520 would indicate that the packed object 520 contains four ID values having an overall length less than three bytes. This scenario is not possible given the above defined packed object 520 format. Note further that there is no need to examine the second byte in order to determine that the first all-zero byte of the supposed packed object's length section 525 is invalid. Thus, a byte whose value is zero at the expected start of a packed object 520 can be used as a data terminating flag pattern.
2.2.1.3 Special Features and External Directory Flags The appearance of predefined bit pattern (e.g., �100�) at the start of a packed object 520, if immediately followed by a valid bit pattern (e.g., a valid EBV-3), may be used as a �Features Flag� to indicate that an optional �Special Features Section� is encoded immediately preceding data section 560. Under normal circumstances, an EBV-3 starting with �100� is redundant and therefore invalid (for example, �100 011� is equivalent to the shorter �011�).
2.2.2 Identifier (ID) Section FIG. 7 depicts an exemplary ID section 530, according to embodiments of the present invention. Each packed object 520 may encode one or more data elements (AI strings, DI strings, etc). The ID section 530 encodes a complete listing of all the identifiers (AIs, DIs, etc) encoded in a packed object 520. To conserve tag bits, each identifier is typically represented as an index, representing an entry into a table of identifier values (referred to herein as �ID header tables�). The ID header table entries define the data system identifiers (e.g., AI or DI) represented by the ID index values. In an embodiment, the identifier index is a byte. As is well known in the art, data system identifiers are used to carry information about a particular scenario in which an RFID tag might be used. For example, in the case of a warehouse, the identifier strings may carry information about an item relating to its Date of Manufacture, Country of Origin and so on.
2.2.2.1 ID Header Table One or more ID header tables may be used in the present invention. Each data system supported may have one or more associated ID header tables. For example, one or more ID header tables may be defined for AI values and one or more header tables may be defined for DI values. Alternatively, an AI ID header table may include one or more values indicating a shift to a different data system (e.g., DI).
2.2.2.2 ID Section Format ID section 530 includes an ID values subsection 732, an ID bits subsection 734, and an ID digits subsection 736. The ID values subsection 732 includes one or more identifier indices (also referred to as �ID values� or �ID Byte values�). The ID values subsection 732 may contain any number of ID values indicating individual data system index identifiers or identifier pairings. An encoder may choose one identifier per packet or many (which constitutes a no cost optional directory for smaller tags).
2.2.2.3 Mini-Directory The combination of length section 525 and identifier section 530 is referred to as �mini-directory� 535. Alternatively, identifier section 530 may be considered a �mini-directory� 535. Mini-directory 535 gives a Reader-Tag communication scenario a degree of random access, without incurring any bit-overhead of adding a full Directory section as does the ISO method. It does this by grouping all the Header ID values for a given packed object 520 at the front of the object, creating a �mini-directory� for each packed object 520. Unlike the ISO Directory method, there is no need to repeat the ID values in two different areas of the tag memory.
2.2.2.4 Identifier Aliases Certain identifiers are globally defined as alphanumeric. However, in certain industries, an identifier defined as alphanumeric may only be encoded as digits. In these cases, an identifier alias can be created in the Header table to indicate to an encoder and/or decoder than the identifier can be treated as a numeric instead of an alphanumeric. For example, Batch/Lot number AI 10 has been defined by GS1 as an alphanumeric. However, certain industries such as the Pharmaceutical industry only use numeric batch/lot numbers. Therefore, an alias header value can be added as a second entry for AI 10 (Batch/Lot number). This second entry still results in data that will be interpreted as a normal AI 10, but the encoded use of the �alias� header value tells the Encoder and Decoder that they can treat the data more efficiently as a variable-length Numeric (with a four bit length, for lot numbers of 5 through 20 digits). In the example illustrated in FIGS. 8A-E, a second entry is added for AI 17 coupled with the numeric version of AI 10. This encoding option, when the user's data content allows it, avoids the need for A/N encoding, saving the A/N Header bits. Furthermore, when the user's Lot is all-numeric, implied object length alternatives, described in Section 2.2.2.1, can be used for further savings.
2.2.3 Auxiliary Identifier (ID) Section An entry in a header table, as part of its definition, can call for various types of auxiliary information (such as bit fields or decimal digits), beyond the complete indication of the ID itself, to aid the data compaction process. The various types of data elements are amenable to different encoding methods, resulting in one or more separately-compressed portions within Aux ID section 540, as called for by the specific IDs on the list.
2.2.4 Special Features Section Special features section 550 is configured to hold one or more data values (referred to as �feature flags�) which define and/or control features specific to one or more packed objects or the user memory bank as a whole. As described above, a flag in length section 525 indicates the presence of the special features section. As illustrated in FIG. 5, when present, the special features section 550 follows Aux ID Section 540.
2.2.5 Data Section Data Section 560 contains the compacted contents of each identifier data string (e.g., AI or DI data strings). Depending on the characteristics of the encoded IDs and data strings, data section 560 may include up to three subsections. The subsections of data section 560 may be bit-aligned (i.e., no pad bits needed between subsections). However, an alternative alignment may be specified in optional special features section 550 (described above). FIG. 9 depicts an exemplary data section 560, according to embodiments of the present invention. Data section 560 may include a custom-compaction subsection 962, a known-length-numerics subsection 964, and an alphanumerics (A/N) subsection 966.
2.3 External Directory A variety of alternatives can be used in the present invention for encoding optional external directory 580, involving differing trade-offs between encoding efficiency versus append efficiency versus random-access reading efficiency. As described above, the presence of an external directory 580 is indicated by predefined indicator pattern. For example, the predefined pattern may be a bit-pattern which would be invalid if used in a packed object (e.g., the six-bit indicator pattern of �100100�). Therefore, the invalid bit pattern can be used to indicate the presence of an external directory. In an embodiment, one or more bit flags are included which indicate the optional levels of external directory 580 support. These bits can immediately follow the indicator pattern but at least some of them could instead preface the actual data bits of optional external directory 580 (which may be located at the front of user memory bank 460, at the end of the series of packed objects 520 a-n, or at the end of the user memory bank 460). The various levels and options of external directory 580 support are described below.
2.3.1 Minimal External Directory Option In the minimal external directory option, external directory 580 provides some data to help a reader more efficiently navigate through a user memory bank 460 containing an unknown number of packed objects 520 a-n. In this embodiment, external directory 580 includes an index to the first empty word of user memory bank 460.
For example, the Index-Length indicator could be defined as a minimum of three bits, where �000�, �001�, . . . �110� indicate an Index length ranging between four and ten bits, used for bank sizes of 4 words, 5 words, 0.10 words, respectively. In addition, if vendors are offering memory sizes in increments of at least 32 bits, then these indicators could be defined to count double-words rather than bytes. The next largest set of length indicators would range from �111000� through �111110�, and so on. Although this approach to length indication is increasingly wasteful as user memory bank 460 size grows, the indicator remains a negligible fraction of bank size.
2.3.2 Medium-Support External Directory Option In the medium-support external directory option, external directory 580 provides a full listing of all the IDs contained in all packed objects 520 a-b in user memory bank 460, accompanied by only the minimum information necessary to find an ID of interest. At a minimum, this would require, as the directory entry for each packed object 520 a-n, an indication of the number of ID values in that packed object 520 (e.g., in EBV-3 format), followed by an exact copy of the ID section of that packed object 520. This level of information is sufficient to allow the Reader to determine that a particular ID is in the �nth� packed object. The reader would then navigate past the first (n−1) Packed Objects, needing only each packed object's length section 525 for navigation. It would then more thoroughly parse the nth packed object in order to retrieve the desired data.
2.3.3 High-Support External Directory Option In the high-support external directory option, in addition to the exact copy of the ID section of the packed object, each packed object's entry would include a complete copy of its length section 525 (instead of just it's EBV-3), indicating the full size of packed object 520. This simple modification to the medium-support directory entry structure brings it nearly to true Random Access, at reasonable incremental bit cost. In this way, once a Reader established the presence of the target ID, it could immediately calculate the starting address of the relevant packed object 520, with no need to first navigate through the preceding packed objects. Furthermore, by using the total length (in bits) of the relevant packed object's 520 directory entry, the reader can calculate the start of Aux ID section 540 of packed object 520, thus in the next Read it can skip over the length section 525 and ID section 530 bits that it has already seen. Even a partial read of packed object's 520 Aux ID section 540 bits may suffice to precisely locate the start of the target's compressed data. Alternately, if the length of the known packed object 520 is small, the reader may determine that it would be faster to simply read the remainder of packed object 520 in one operation.
2.3.4 �Split� Packed Objects Directory Structure If the presence of an external directory 580 is indicated (e.g., by a flag bit or pattern), the structure of the external directory 580 may follow one of the formats described above. Additional bits on each tag may follow the Directory bit to qualify the chosen Directory method.
2.4 Alternate Packed Object Format As an alternative to the above format for a packed object 520, an expandable packed object 520 size indicator that can fill any size memory bank with a single Packed Object 520 can be used for user memory bank 460.
3. Methods A serious problem in applying known formats such as ISO to Gen 2 tags (one of the problems addressed by the embodiments described in the present application) is the need to support an efficient Read command that ideally transfers no more bits over the air than is necessary to search for the desired tag data elements. In this regard, Gen 2 is a particular challenge, because a Gen 2 Read command has only two �length� options when reading user memory bank 460. Either a length of �0� is requested in which case the tag emits the entire contents of that memory bank, even if it is all or mostly unused and empty, or a specific read length is requested, in which case the Read command fails if too many words of data are requested.
3.1 Methods for Efficient Reading of Tag Population FIGS. 14A and B depict a flowchart 1400 of an exemplary method for optimizing a random access read of tags having packed object configurations, according to embodiments of the present invention. Flowchart 1400 is described with continued reference to the embodiments of FIGS. 4-13. However, flowchart 1400 is not limited to those embodiments. Note that not all of the steps in flowchart 1400 have to occur in the order shown.
During step 1432, a reader may examine the appropriate Header table(s) to determine which segment the identifiers data will be encoded into. This step allows the reader to minimize over-the-air bit transfers by skipping over any preceding segments that can't contain the target identifier data (and of course skipping any trailing segments as well). For instance, if the reader was asked for AI 31 in, and the tag's list of ID's showed (in the first 3 bytes of tag memory after the Length Indicator) AI 17, AI 310n, and 311n, the reader could minimize bit transfer by skipping CustomCompaction subsection 962 of packed object 520 (which would encode the sixteen bits of data for AI 17). Since in this case the encoder chose to include two always-numeric data elements in the same packed object 520, the decoder calculates the number of digits encoded (in this case, twelve) and then fetches from the tag at least the corresponding number of base-10 bits (in this case, 40). After decoding these 40 bits back into twelve digits, the decoder skips the first six digits (which would have to represent the data of AI 310n), and uses following six digits (the data of AI 311n). The fetches would include as few �extra� bits in front of and behind those needed bits as is necessary to achieve Word alignment of the Read operation (a Gen 2 requirement).
3.2 Methods for Decoding an Alphanumeric Subsection FIGS. 15A-C depicts a flowchart 1500 of an exemplary method for decoding an alphanumeric subsection 966 of a packed object 520, according to embodiments of the present invention. Flowchart 1500 is described with continued reference to the embodiments of FIGS. 4-13. However, flowchart 1500 is not limited to those embodiments. Note that not all of the steps in flowchart 1500 have to occur in the order shown.
3.3 Methods for Encoding Data Items The following section describes methods for encoding a packed object. Encoding may be performed by any suitable computing device, including but not limited to, an RFID reader. FIG. 17 depicts a flowchart 1700 of an exemplary high-level method for encoding a packed object, according to embodiments of the present invention. Flowchart 1700 is described with continued reference to the embodiments of FIGS. 4-13. However, flowchart 1700 is not limited to those embodiments. Note that not all of the steps in flowchart 1700 have to occur in the order shown. Not all techniques that could be used to encode a packed object are described in flowchart 1700. These additional techniques are described above or would be apparent from the description of user memory format 460.
3.4 Minimized Read Time Optimizations of Reads of Entire User Memory When commanded to read all of user memory bank 460 of a population of tags, total Read time can be optimized, using averages obtained from previous tags of the population, and if needed, using the length information obtained from an initial read of the head of packed object 520 structure of each newly-singulated tag.
4. Alternate Embodiments 4.1 Direct Length A minor modification to the format design of user memory bank 460 described above can be used to provide additional information for optimizing searches. In this alternative embodiment, the exact number of bytes necessary to gather a complete list of all the data ID's of the packet is fully defined (in length bytes at the front of each Packed Object 520) in full 2-to-4 digit form (as well as the full DI identifier if present).
4.2 Memory Size Indication The below alternative embodiment encodes a memory-size indication starting in the first byte of user memory bank 460. The purpose of this indicator is so that readers can quickly ascertain the extent of user memory bank 460 in the same Read operation that provides the remainder of necessary system and formatting information. This provides a significant operational advantage over current mechanisms which requires not only a read of a different memory bank (TID) but also a further lookup operation to obtain memory size from the TID.
4.3 Digits Identifier By default, the defined A/N character sets exclude the 10 digits from their sets (because they are more efficiently handled by the Base 10 set). However, there can be cases where this exclusion can hurt efficiency, notably where a single digit or two within a long run of A/N data prevents the encoder from run-length encoding a large portion of the data (which would have cut down the number of bits in the Character Map). An option would be for the A/N Header definition to include an additional bit, flagging whether or not the Digits are included in the non-numeric base.
4.4 Access Control The system and methods described above may include additional techniques for controlling access to one or more portions of user memory bank 460. For example, the format may include the ability to incrementally add new data items during the service life of a tag, but with an option to lock existing data items so they cannot be altered. In addition, the format may include the ability to write lock at time of tag manufacture (or optionally hard-code) system information that is known at time of manufacture and will not change thereafter (such as the size of the tag memory and the existence of sensor inputs) and the ability to write-lock any other system information (such as data system format) that cannot be known at time of manufacture
5. Example Computer System Embodiments In this document, the terms �computer program medium� and �computer usable medium� are used to generally refer to media such as a removable storage unit, a hard disk installed in hard disk drive, and signals (i.e., electronic, electromagnetic, optical, or other types of signals capable of being received by a communications interface). These computer program products are means for providing software to a computer system. The invention, in an embodiment, is directed to such computer program products.
6. Conclusion While various embodiments of the present invention have been described above, it should be understood that they have been presented by way of example only, and not limitation. It will be apparent to persons skilled in the relevant art that various changes in form and detail can be made therein without departing from the spirit and scope of the invention. Thus, the breadth and scope of the present invention should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.
Referenced byCiting PatentFiling datePublication dateApplicantTitleUS7654455 *Jun 3, 2005Feb 2, 2010Hewlett-Packard Development Company, L.P.Method and apparatus for achieving a tailored content response based upon a product identifier combined with a user identifier and a device identifierUS7739468 *May 30, 2007Jun 15, 2010Min-Ta ChangData protection system for controlling data entry point employing RFID tagUS8115595 *Apr 25, 2006Feb 14, 2012Lg Electronics Inc.Reader control systemUS8115604Apr 25, 2006Feb 14, 2012Lg Electronics Inc.Reader control systemUS8249889Jan 31, 2005Aug 21, 2012Hewlett-Packard Development Company, L.P.Providing information regarding a productUS8266019Dec 22, 2004Sep 11, 2012Hewlett-Packard Development Company, L.P.Optimizing retrieval of object-associated informationUS8378790Nov 24, 2010Feb 19, 2013Lg Electronics Inc.Reader control systemUS8385414 *Nov 30, 2010Feb 26, 2013International Business Machines CorporationMultimedia size reduction for database optimizationUS8519829Feb 14, 2011Aug 27, 2013Omron CorporationTag communication apparatus, tag communication apparatus control method, and tag communication apparatus control programUS8818353 *Jun 8, 2012Aug 26, 2014Ipinion, Inc.Optimizing mobile user data storageUS20100161895 *Dec 22, 2008Jun 24, 2010Qualls William RSecuring data on data cartridgesUS20120136902 *Nov 30, 2010May 31, 2012International Business Machines CorporationMultimedia size reduction for database optimization* Cited by examinerClassifications U.S. Classification711/100, 340/10.1, 340/572.1, 711/213, 711/171, 340/10.51International ClassificationG06F12/00Cooperative ClassificationG06K7/0008European ClassificationG06K7/00ELegal EventsDateCodeEventDescriptionMay 28, 2014FPAYFee paymentYear of fee payment: 4Apr 30, 2013CCCertificate of correctionMay 29, 2007ASAssignmentOwner name: SYMBOL TECHNOLOGIES, INC., NEW YORKFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:SCHUESSLER, FREDERICK;REEL/FRAME:019412/0445Effective date: 20070529RotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services