Anonymous RFID tag ics

Abstract

A tag can be configured with an anonymous mode of operation in which identifiers are obfuscated into anonymized identifier codes. An anonymized identifier code may be deanonymized if a hint and a code used to generate the hint are known. An RFID reader may inventory the tag while it is operating in the anonymous mode and obtain the anonymized identifier code, optionally receive a collision-resolution code, and a hint based on one of the received codes. The RFID reader may provide the anonymized identifier code, the hint, and the code used to generate the hint to a service. The service may use the hint and the code to identify a tag key associated with the radio tag IC. The tag key may then be used to recover an identifier from the anonymized identifier code.

Description

ANONYMOUS RFID TAG ICSCROSS REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to U.S. Provisional Patent Application Serial No. 63 / 710,750 filed on October 23, 2024. The disclosures of the Provisional Application are hereby incorporated by reference in their entirety.BACKGROUND

[0002] Radio-Frequency Identification (RFID) systems typically include RFID readers, also known as RFID reader / writers or RFID interrogators, and RFID tags, also known as radio tags. RFID systems can be used in many ways for locating and identifying objects to which the tags are attached. RFID systems are useful in product-related and service-related industries for tracking objects being processed, inventoried, or handled. In such cases, an RFID tag is usually attached to an individual item, or to its package. The RFID tag typically includes, or is, a radiofrequency (RF) integrated circuit (IC). Such an RFIC may be referred to as an RFID IC or a radio IC.

[0003] In principle, RFID techniques entail using an RFID reader to inventory one or more RFID tags, where inventorying involves singulating a tag, receiving an identifier from a tag, and / or acknowledging a received identifier (e.g., by transmitting an acknowledge command). “Singulated” is defined as a reader singling-out one tag, potentially from among multiple tags, for a reader-tag dialog. “Identifier” is defined as a number identifying the tag or the item to which the tag is attached, such as a tag identifier (TID), electronic product code (EPC), etc. An “inventory round” is defined as a reader staging RFID tags for successive inventorying. The reader transmitting an RF wave performs the inventory. The RF wave is typically electromagnetic, at least in the far field. The RF wave can also be predominantly electric or magnetic in the near or transitional near field. The RF wave may encode one or more commands that instruct the tags to perform one or more actions. The operation of an RFID reader sending commands to an RFID tag is sometimes known as the reader “interrogating” the tag.

[0004] In typical RFID systems, an RFID reader transmits a modulated RF inventory signal (a command), receives a tag reply, and transmits an RF acknowledgement signal responsive to the tag reply. A tag that replies to the interrogating RF wave does so by transmitting back another RF wave. The tag either generates the transmitted back RF wave originally, or by reflecting back a portion of the interrogating RF wave in a process known as backscatter. Backscatter may take place in a number of ways.BRIEF SUMMARY

[0005] This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended as an aid in determining the scope of the claimed subject matter.

[0006] Some examples are directed to a method for identifying items, which includes receiving, from a requesting entity, an anonymized identifier code, a hint, and optionally a second code, where the anonymized identifier code, the hint, and the second code originate from wireless communications with a radio IC associated with a tagged item; identifying a key associated with the radio IC by comparing the hint and at least a portion of one of the received codes to a plurality of code-hint pairs; using the identified key to recover an identifier from the anonymized identifier code; determining an entity designation for the tagged item; and sending the recovered identifier to the designated entity.

[0007] These and other features and advantages will be apparent from a reading of the following detailed description and a review of the associated drawings. It is to be understood that both the foregoing general description and the following detailed description are explanatory only and are not restrictive of aspects as claimed.BRIEF DESCRIPTION OF THE DRAWINGS

[0008] The following Detailed Description proceeds with reference to the accompanying drawings, in which:

[0009] FIG. l is a block diagram of components of an RFID system.

[0010] FIG. 2 is a diagram showing components of a passive RFID tag, such as a tag that can be used in the system of FIG. 1.

[0011] FIG. 3 is a conceptual diagram for explaining a half-duplex mode of communication between the components of the RFID system of FIG. 1.

[0012] FIG. 4 is a block diagram showing a detail of an RFID tag, such as the one shown in FIG. 2.

[0013] FIG. 5 A and 5B illustrate signal paths during tag-to-reader and reader-to-tag communications in the block diagram of FIG. 4.

[0014] FIG. 6 is a block diagram showing a detail of an RFID reader system, such as the one shown in FIG. 1.

[0015] FIG. 7 is a diagram of an example RFID tag IC memory configuration, according to embodiments.

[0016] FIG. 8 is a block diagram illustrating an RFID system enabling the use of anonymous tags, according to embodiments.

[0017] FIG. 9 is a flow diagram illustrating a method for a service to deanonymize an anonymous RFID tag, according to embodiments.

[0018] FIG. 10 is a flow diagram illustrating a method for an RFID tag to anonymize its identifier, according to embodiments.DETAILED DESCRIPTION

[0019] In the following detailed description, references are made to the accompanying drawings that form a part hereof, and in which are shown by way of illustration specific embodiments or examples. These embodiments or examples may be combined, other aspects may be utilized, and structural changes may be made without departing from the spirit or scope of the present disclosure. The following detailed description is therefore not to be taken in a limiting sense, and the scope of the present invention is defined by the appended claims and their equivalents.

[0020] As used herein, “memory” is one of ROM, RAM, SRAM, DRAM, NVM, EEPROM, FLASH, Fuse, MRAM, FRAM, and other similar volatile and nonvolatile information-storage technologies. Some portions of memory may be writeable and some not. “Instruction” refers to a request to a tag to perform a single explicit action (e.g., write data into memory). “Command” refers to a reader request for one or more tags to perform one or more actions, and includes one or more tag instructionspreceded by a command identifier or command code that identifies the command and / or the tag instructions. “Program” refers to a request to a tag to perform a set or sequence of instructions (e.g., read a value from memory and, if the read value is less than a threshold then lock a memory word). “Protocol” refers to an industry standard for communications between a reader and a tag (and vice versa). One such protocol is the Class- 1 Generation-2 UHF RFID Protocol for Communications at 860 MHz - 960 MHz by GS1 EPCglobal, Inc. (“the Gen2 Protocol”), versions up to 3.0 of which are hereby incorporated by reference

[0021] RFID tags are often configured to be responsive to commands received from any RFID reader, and as such they readily provide their unique identifier to any such reader. While this feature is often not problematic, consumers are increasingly becoming owners of items that are tagged with tags, either purchasing them with already attached tags or attaching tags to their own items. In some cases, a unique identifier of a tag may reveal information about an item that the tag is associated with, or about the tag itself. In addition, the combination of several unique identifiers obtained from a consumer’s items may further reveal information about the consumer, information about a consumer’s items as a whole, or information about the RFID tags themselves. Therefore, this property of tags may intrude on the privacy of consumers, because any third party can use a reader to read unique identifiers from tags of consumers.

[0022] To combat this privacy issue, and maintain regulatory compliance with some sustainability efforts, tags can be configured with an anonymous mode of operation. Tags operating in the anonymous mode or “anonymous tags” are configured to obfuscate any identifier before sending the obfuscated identifier to a reader. An obfuscated (or “anonymized”) identifier does not provide information about the tag or associated item. Anonymous tags are configured to provide anonymized identifier codes in place of raw-data identifiers. Anonymized identifier codes may be configured to only be deanonymized under certain circumstances.

[0023] FIG. 1 is a diagram of the components of a typical RFID system 100, incorporating embodiments. An RFID reader 110 and a nearby RFID tag 120 communicate via RF signals 112 and 126. When sending data to tag 120, reader 110 may generate RF signal 112 by encoding the data, modulating an RF waveform with the encoded data, and transmitting the modulated RF waveform as RF signal 112. Inturn, tag 120 may receive RF signal 112, demodulate encoded data from RF signal 112, and decode the encoded data. Similarly, when sending data to reader 110 tag 120 may generate RF signal 126 by encoding the data, modulating an RF waveform with the encoded data, and causing the modulated RF waveform to be sent as RF signal 126. The data sent between reader 110 and tag 120 may be represented by symbols, also known as RFID symbols. A symbol may be a delimiter, a calibration value, or implemented to represent binary data, such as “0” and “1”, if desired. Upon processing by reader 110 and tag 120, symbols may be treated as values, numbers, or any other suitable data representations.

[0024] The RF waveforms transmitted by reader 110 and / or tag 120 may be in a suitable range of frequencies, such as those near 900 MHz, 13.56 MHz, or similar. In some embodiments, RF signals 112 and / or 126 may include non-propagating RF signals, such as reactive near-field signals or similar. RFID tag 120 may be active or battery-assisted (i.e., possessing its own power source), or passive. In the latter case, RFID tag 120 may harvest power from RF signal 112.

[0025] FIG. 2 is a diagram of an RFID tag 220, which may function as tag 120 of FIG. 1. Tag 220 may be formed on a substantially planar inlay 222, which can be made in any suitable way. Tag 220 includes a circuit which may be implemented as an IC 224. In some embodiments IC 224 is fabricated in complementary metal-oxide semiconductor (CMOS) technology. In other embodiments IC 224 may be fabricated in other technologies such as bipolar junction transistor (BJT) technology, metalsemiconductor field-effect transistor (MESFET) technology, and others as will be well known to those skilled in the art. IC 224 is arranged on inlay 222.

[0026] Tag 220 also includes an antenna for transmitting and / or interacting with RF signals. In some embodiments the antenna can be etched, deposited, and / or printed metal on inlay 222; conductive thread formed with or without inlay 222; nonmetallic conductive (such as graphene) patterning on inlay 222; a first antenna coupled inductively, capacitively, or galvanically to a second antenna; or can be fabricated in myriad other ways that exist for forming antennas to receive RF waves. In some embodiments the antenna may even be formed in IC 224. Regardless of the antenna type, IC 224 is electrically coupled to the antenna via suitable IC contacts (not shown in FIG. 2). The term “electrically coupled” as used herein may mean a direct electrical connection, or it may mean a connection that includes one or more intervening circuitblocks, elements, or devices. The “electrical” part of the term “electrically coupled” as used in this document shall mean a coupling that is one or more of ohmic / galvanic, capacitive, and / or inductive. Similarly, the terms “electrically isolated” or “electrically decoupled” as used herein mean that electrical coupling of one or more types (e.g., galvanic, capacitive, and / or inductive) is not present, at least to the extent possible. For example, elements that are electrically isolated from each other are galvanically isolated from each other, capacitively isolated from each other, and / or inductively isolated from each other. Of course, electrically isolated components will generally have some unavoidable stray capacitive or inductive coupling between them, but the intent of the isolation is to minimize this stray coupling when compared with an electrically coupled path.

[0027] IC 224 is shown with a single antenna port, comprising two IC contacts electrically coupled to two antenna segments 226 and 228 which are shown here forming a dipole. Many other embodiments are possible using any number of ports, contacts, antennas, and / or antenna segments. Antenna segments 226 and 228 are depicted as separate from IC 224, but in other embodiments the antenna segments may alternatively be formed on IC 224. Tag antennas according to embodiments may be designed in any form and are not limited to dipoles. For example, the tag antenna may be a patch, a slot, a loop, a coil, a horn, a spiral, a monopole, microstrip, stripline, or any other suitable antenna.

[0028] Diagram 250 depicts top and side views of tag 252, formed using a strap. Tag 252 differs from tag 220 in that it includes a substantially planar strap substrate 254 having strap contacts 256 and 258. IC 224 is mounted on strap substrate 254 such that the IC contacts on IC 224 electrically couple to strap contacts 256 and 258 via suitable connections (not shown). Strap substrate 254 is then placed on inlay 222 such that strap contacts 256 and 258 electrically couple to antenna segments 226 and 228. Strap substrate 254 may be affixed to inlay 222 via pressing, an interface layer, one or more adhesives, or any other suitable means.

[0029] Diagram 260 depicts a side view of an alternative way to place strap substrate 254 onto inlay 222. Instead of strap substrate 254’ s surface, including strap contacts 256 / 258, facing the surface of inlay 222, strap substrate 254 is placed with its strap contacts 256 / 258 facing away from the surface of inlay 222. Strap contacts 256 / 258 can then be either capacitively coupled to antenna segments 226 / 228 through strapsubstrate 254, or conductively coupled using a through-via which may be formed by crimping strap contacts 256 / 258 to antenna segments 226 / 228. In some embodiments, the positions of strap substrate 254 and inlay 222 may be reversed, with strap substrate 254 mounted beneath inlay 222 and strap contacts 256 / 258 electrically coupled to antenna segments 226 / 228 through inlay 222. Of course, in yet other embodiments strap contacts 256 / 258 may electrically couple to antenna segments 226 / 228 through both inlay 222 and strap substrate 254.

[0030] In operation, the antenna couples with RF signals in the environment and propagates the signals to IC 224, which may both harvest power and respond if appropriate, based on the incoming signals and the IC’s internal state. If IC 224 uses backscatter modulation then it may generate a response signal (e.g., signal 126) from an RF signal in the environment (e.g., signal 112) by modulating the antenna’s reflectance. Electrically coupling and uncoupling the IC contacts of IC 224 can modulate the antenna’s reflectance, as can varying the admittance or impedance of a shunt-connected or series-connected circuit element which is coupled to the IC contacts. If IC 224 is capable of transmitting signals (e.g., has its own power source, is coupled to an external power source, and / or can harvest sufficient power to transmit signals), then IC 224 may respond by transmitting response signal 126. In the embodiments of FIG. 2, antenna segments 226 and 228 are separate from IC 224. In other embodiments, the antenna segments may alternatively be formed on IC 224.

[0031] An RFID tag such as tag 220 is often attached to or associated with an individual item or the item packaging. An RFID tag may be fabricated and then attached to the item or packaging, may be partly fabricated before attachment to the item or packaging and then completely fabricated upon attachment to the item or packaging, or the manufacturing process of the item or packaging may include the fabrication of the RFID tag. In some embodiments, the RFID tag may be integrated into the item or packaging. In this case, portions of the item or packaging may serve as tag components. For example, conductive item or packaging portions may serve as tag antenna segments or contacts. Nonconductive item or packaging portions may serve as tag substrates or inlays. If the item or packaging includes integrated circuits or other circuitry, some portion of the circuitry may be configured to operate as part or all of an RFID tag IC. Thus, an “RFID IC” need not be distinct from an item, but more generally refers to the item containing an RFID IC and antenna capable ofinteracting with RF waves and receiving and responding to RFID signals. Because the boundaries between IC, tag, and item are thus often blurred, the terms “RFID IC”, “RFID tag”, “tag”, “radio IC”, “radio tag IC”, or “tag IC” as used herein may refer to the IC, the tag, or even to the item as long as the referenced element is capable of RFID functionality.

[0032] The components of the RFID system of FIG. 1 may communicate with each other in any number of modes. One such mode is called full duplex, where both reader 110 and tag 120 can transmit at the same time. In some embodiments, RFID system 100 may be capable of full duplex communication. Another such mode, which may be more suitable for passive tags, is called half-duplex, and is described below.

[0033] FIG. 3 is a conceptual diagram 300 for explaining half-duplex communications between the components of the RFID system of FIG. 1, in this case with tag 120 implemented as a passive tag. The explanation is made with reference to a TIME axis, and also to a human metaphor of “talking” and “listening”. The actual technical implementations for “talking” and “listening” are now described.

[0034] In a half-duplex communication mode, RFID reader 110 and RFID tag 120 talk and listen to each other by taking turns. As seen on axis TIME, reader 110 talks to tag 120 during intervals designated “R- T”, and tag 120 talks to reader 110 during intervals designated “T- R”. For example, a sample R- T interval occurs during time interval 312, during which reader 110 talks (block 332) and tag 120 listens (block 342). A following sample T- R interval occurs during time interval 326, during which reader 110 listens (block 336) and tag 120 talks (block 346). Interval 312 may be of a different duration than interval 326 - here the durations are shown approximately equal only for purposes of illustration.

[0035] During interval 312, reader 110 transmits a signal such as signal 112 described in FIG. 1 (block 352), while tag 120 receives the reader signal (block 362), processes the reader signal to extract data, and harvests power from the reader signal. While receiving the reader signal, tag 120 does not backscatter (block 372), and therefore reader 110 does not receive a signal from tag 120 (block 382).

[0036] During interval 326, also known as a backscatter time interval or backscatter interval, reader 110 does not transmit a data-bearing signal. Instead, reader 110 transmits a continuous wave (CW) signal, which is a carrier that generally does notencode information. The CW signal provides energy for tag 120 to harvest as well as a waveform that tag 120 can modulate to form a backscatter response signal.Accordingly, during interval 326 tag 120 is not receiving a signal with encoded information (block 366) and instead modulates the CW signal (block 376) to generate a backscatter signal such as signal 126 described in FIG. 2. Tag 120 may modulate the CW signal to generate a backscatter signal by adjusting its antenna reflectance, as described above. Reader 110 then receives and processes the backscatter signal (block 386).

[0037] FIG. 4 is a block diagram showing a detail of an RFID IC, such as IC 224 in FIG. 2. Electrical circuit 424 may be implemented in an IC, such as IC 224. Circuit 424 implements at least two IC contacts 432 and 433, suitable for coupling to antenna segments such as antenna segments 226 / 228 in FIG. 2. When two IC contacts form the signal input from and signal return to an antenna they are often referred-to as an antenna port. IC contacts 432 and 433 may be made in any suitable way, such as from electrically-conductive pads, bumps, or similar. In some embodiments circuit 424 implements more than two IC contacts, especially when configured with multiple antenna ports and / or to couple to multiple antennas.

[0038] Circuit 424 includes signal-routing section 435 which may include signal wiring, signal-routing buses, receive / transmit switches, and similar that can route signals between the components of circuit 424. IC contacts 432 / 433 may couple galvanically, capacitively, and / or inductively to signal-routing section 435. For example, optional capacitors 436 and / or 438 may capacitively couple IC contacts 432 / 433 to signal-routing section 435, thereby galvanically decoupling IC contacts 432 / 433 from signal-routing section 435 and other components of circuit 424.

[0039] Capacitive coupling (and the resultant galvanic decoupling) between IC contacts 432 and / or 433 and components of circuit 424 is desirable in certain situations. For example, in some RFID tag embodiments IC contacts 432 and 433 may galvanically connect to terminals of a tuning loop on the tag. In these embodiments, galvanically decoupling IC contact 432 from IC contact 433 may prevent the formation of a DC short circuit between the IC contacts through the tuning loop.

[0040] Capacitors 436 / 438 may be implemented within circuit 424 and / or partly or completely external to circuit 424. For example, a dielectric or insulating layer on thesurface of the IC containing circuit 424 may serve as the dielectric in capacitor 436 and / or capacitor 438. As another example, a dielectric or insulating layer on the surface of a tag substrate (e.g., inlay 222 or strap substrate 254) may serve as the dielectric in capacitors 436 / 438. Metallic or conductive layers positioned on both sides of the dielectric layer (i.e., between the dielectric layer and the IC and between the dielectric layer and the tag substrate) may then serve as terminals of the capacitors 436 / 438. The conductive layers may include IC contacts (e.g., IC contacts 432 / 433), antenna segments (e.g., antenna segments 226 / 228), or any other suitable conductive layers.

[0041] Circuit 424 includes a rectifier and PMU (Power Management Unit) 441 that harvests energy from the RF signal incident on antenna segments 226 / 228 to power the circuits of IC 424 during either or both reader-to-tag (R->T) and tag-to-reader (T- R) intervals. Rectifier and PMU 441 may be implemented in any way known in the art, and may include one or more components configured to convert an alternating-current (AC) or time-varying signal into a direct-current (DC) or substantially time-invariant signal.

[0042] Circuit 424 also includes a demodulator 442, a processing block 444, a memory 450, and a modulator 446. Demodulator 442 demodulates the RF signal received via IC contacts 432 / 433, and may be implemented in any suitable way, for example using a slicer, an amplifier, and other similar components. Processing block 444 receives the output from demodulator 442, performs operations such as command decoding, memory interfacing, and other related operations, and may generate an output signal for transmission. Processing block 444 may be implemented in any suitable way, for example by combinations of one or more of a processor, memory, decoder, encoder, and other similar components. Memory 450 stores data 452, and may be at least partly implemented as permanent or semi-permanent memory such as nonvolatile memory (NVM), EEPROM, ROM, or other memory types configured to retain data 452 even when circuit 424 does not have power. Processing block 444 may be configured to read data from and / or write data to memory 450.

[0043] Modulator 446 generates a modulated signal from the output signal generated by processing block 444. In one embodiment, modulator 446 generates the modulated signal by driving the load presented by antenna segment(s) coupled to IC contacts 432 / 433 to form a backscatter signal as described above. In another embodiment,modulator 446 includes and / or uses a transmitter to generate and transmit the modulated signal via antenna segment(s) coupled to IC contacts 432 / 433. Modulator 446 may be implemented in any suitable way, for example using a switch, driver, amplifier, and other similar components. Demodulator 442 and modulator 446 may be separate components, combined in a single transceiver circuit, and / or part of processing block 444.

[0044] In some embodiments, particularly in those with more than one antenna port, circuit 424 may contain multiple demodulators, rectifiers, PMUs, modulators, processing blocks, and / or memories.

[0045] FIG. 5 A shows version 524-A of components of circuit 424 of FIG. 4, further modified to emphasize a signal operation during a R- T interval (e.g., time interval 312 of FIG. 3). During the R- T interval, demodulator 442 demodulates an RF signal received from IC contacts 432 / 433. The demodulated signal is provided to processing block 444 as C_IN, which in some embodiments may include a received stream of symbols. Rectifier and PMU 441 may be active, for example harvesting power from an incident RF waveform and providing power to demodulator 442, processing block 444, and other circuit components. During the R- T interval, modulator 446 is not actively modulating a signal, and in fact may be decoupled from the RF signal. For example, signal routing section 435 may be configured to decouple modulator 446 from the RF signal, or an impedance of modulator 446 may be adjusted to decouple it from the RF signal.

[0046] FIG. 5B shows version 524-B of components of circuit 424 of FIG. 4, further modified to emphasize a signal operation during a T- R interval (e.g., time interval 326 of FIG. 3). During the T- R interval, processing block 444 outputs a signal C OUT, which may include a stream of symbols for transmission. Modulator 446 then generates a modulated signal from C OUT and sends the modulated signal via antenna segment(s) coupled to IC contacts 432 / 433, as described above. During the T- R interval, rectifier and PMU 441 may be active, while demodulator 442 may not be actively demodulating a signal. In some embodiments, demodulator 442 may be decoupled from the RF signal during the T- R interval. For example, signal routing section 435 may be configured to decouple demodulator 442 from the RF signal, or an impedance of demodulator 442 may be adjusted to decouple it from the RF signal.

[0047] In typical embodiments, demodulator 442 and modulator 446 are operable to demodulate and modulate signals according to a protocol, such as the Gen2 Protocol mentioned above. In embodiments where circuit 424 includes multiple demodulators modulators, and / or processing blocks, each may be configured to support different protocols or different sets of protocols. A protocol specifies, in part, symbol encodings, and may include a set of modulations, rates, timings, or any other parameter associated with data communications. A protocol can be a variant of an internationally ratified protocol such as the Gen2 Protocol, for example including fewer or additional commands than the ratified protocol calls for, and so on. In some instances, additional commands may sometimes be called custom commands.

[0048] FIG. 6 depicts an RFID reader system 600 according to embodiments. Reader system 600 is configured to communicate with RFID tags and optionally to communicate with entities external to reader system 600, such as a service 632.Reader system 600 includes at least one reader module 602, configured to transmit signals to and receive signals from RFID tags. Reader system 600 further includes at least one local controller 612, and in some embodiments includes at least one remote controller 622. Controllers 612 and / or 622 are configured to control the operation of reader module 602, process data received from RFID tags communicating through reader module 602, communicate with external entities such as service 632, and otherwise control the operation of reader system 600.

[0049] In some embodiments, reader system 600 may include multiple reader modules, local controllers, and / or remote controllers. For example, reader system 600 may include at least one other reader module 610, at least one other local controller 620, and / or at least one other remote controller 630. A single reader module may communicate with multiple local and / or remote controllers, a single local controller may communicate with multiple reader modules and / or remote controllers, and a single remote controller may communicate with multiple reader modules and / or local controllers. Similarly, reader system 600 may be configured to communicate with multiple external entities, such as other reader systems (not depicted) and multiple services (for example, services 632 and 640).

[0050] Reader module 602 includes a modulator / encoder block 604, a demodulator / decoder block 606, and an interface block 608. Modulator / encoder block 604 may encode and modulate data for transmission to RFID tags. Demodulator / decoderblock 606 may demodulate and decode signals received from RFID tags to recover data sent from the tags. The modulation, encoding, demodulation, and decoding may be performed according to a protocol or specification, such as the Gen2 Protocol. Reader module 602 may use interface block 608 to communicate with local controller 612 and / or remote controller 622, for example to exchange tag data, receive instructions or commands, or to exchange other relevant information.

[0051] Reader module 602 and blocks 604 / 606 are coupled to one or more antennas and / or antenna drivers (not depicted), for transmitting and receiving RF signals. In some embodiments, reader module 602 is coupled to multiple antennas and / or antenna drivers. In these embodiments, reader module 602 may transmit and / or receive RF signals on the different antennas in any suitable scheme. For example, reader module 602 may switch between different antennas to transmit and receive RF signals, transmit on one antenna but receive on another antenna, or transmit and / or receive on multiple antennas simultaneously. In some embodiments, reader module 602 may be coupled to one or more phased-array or synthesized-beam antennas whose beams can be generated and / or steered, for example by reader module 602, local controller 612, and / or remote controller 622.

[0052] Modulator / encoder block 604 and / or demodulator / decoder block 606 may be configured to perform conversion between analog and digital signals. For example, modulator / encoder block 604 may convert a digital signal received via interface block 608 to an analog signal for subsequent transmission, and demodulator / decoder block 606 may convert a received analog signal to a digital signal for transmission via interface block 608.

[0053] Local controller 612 includes a processor block 614, a memory 616, and an interface 618. Remote controller 622 includes a processor block 624, a memory 626, and an interface 628. Local controller 612 differs from remote controller 622 in that local controller 612 is collocated or at least physically near reader module 602, whereas remote controller 622 is not physically near reader module 602.

[0054] Processor blocks 614 and / or 624 may be configured to, alone or in combination, provide different functions. Such functions may include the control of other components, such as memory, interface blocks, reader modules, and similar; communication with other components such as reader module 620, other readersystems, services 632 / 640, and similar; data-processing or algorithmic processing such as encryption, decryption, authentication, and similar; or any other suitable function. In some embodiments, processor blocks 614 / 624 may be configured to convert analog signals to digital signals or vice-versa, as described above in relation to blocks 604 / 606; processor blocks 614 / 624 may also be configured to perform any suitable analog signal processing or digital signal processing, such as filtering, carrier cancellation, noise determination, and similar.

[0055] Processor blocks 614 / 624 may be configured to provide functions by execution of instructions or applications, which may be retrieved from memory (for example, memory 616 and / or 626) or received from some other entity. Processor blocks 614 / 624 may be implemented in any suitable way. For example, processor blocks 614 / 624 may be implemented using digital and / or analog processors such as microprocessors and digital-signal processors (DSPs); controllers such as microcontrollers; software running in a machine such as a general purpose computer; programmable circuits such as field programmable gate arrays (FPGAs), field-programmable analog arrays (FPAAs), programmable logic devices (PLDs), application specific integrated circuits (ASIC), any combination of one or more of these; and equivalents.

[0056] Memories 616 / 626 are configured to store information, and may be implemented in any suitable way, such as the memory types described above, any combination thereof, or any other known memory or information storage technology. Memories 616 / 626 may be implemented as part of their associated processor blocks (e.g., processor blocks 614 / 624) or separately. Memories 616 / 626 may store instructions, programs, or applications for processor blocks 614 / 624 to execute. Memories 616 / 626 may also store other data, such as files, media, component configurations or settings, etc.

[0057] In some embodiments, memories 616 / 626 store tag data. Tag data may be data read from tags, data to be written to tags, and / or data associated with tags or tagged items. Tag data may include identifiers for tags such as electronic product codes (EPCs), tag identifiers (TIDs), or any other information suitable for identifying individual tags. Tag data may also include tag passwords, tag profiles, tag cryptographic keys (secret or public), tag key generation algorithms, and any other suitable information about tags or items associated with tags.

[0058] Memories 616 / 626 may also store information about how reader system 600 is to operate. For example, memories 616 / 626 may store information about algorithms for encoding commands for tags, algorithms for decoding signals from tags, communication and antenna operating modes, encryption / authentication algorithms, tag location and tracking algorithms, cryptographic keys and key pairs (such as public / private key pairs) associated with reader system 600 and / or other entities, electronic signatures, and similar.

[0059] Interface blocks 608, 618, and 628 are configured to communicate with each other and with other suitably configured interfaces. The communications between interface blocks occur via the exchange of signals containing data, instructions, commands, or any other suitable information. For example, interface block 608 may receive data to be written to tags, information about the operation of reader module 602 and its constituent components, and similar; and may send data read from tags. Interface blocks 618 and 628 may send and receive tag data, information about the operation of other components, other information for enabling local controller 612 and remote controller 622 to operate in conjunction, and similar. Interface blocks 608 / 618 / 628 may also communicate with external entities, such as services 632, 640, other services, and / or other reader systems.

[0060] Interface blocks 608 / 618 / 628 may communicate using any suitable wired or wireless means. For example, interface blocks 608 / 618 / 628 may communicate over circuit traces or interconnects, or other physical wires or cables, and / or using any suitable wireless signal propagation technique. In some embodiments, interface blocks 608 / 618 / 628 may communicate via an electronic communications network, such as a local area network (LAN), a metropolitan area network (MAN), a wide area network (WAN), a network of networks such as the internet. Communications from interface blocks 608 / 618 / 628 may be secured, for example via encryption and other electronic means, or may be unsecured.

[0061] Reader system 600 may be implemented in any suitable way. One or more of the components in reader system 600 may be implemented as integrated circuits using CMOS technology, BJT technology, MESFET technology, and / or any other suitable physical implementation technology. Components may also be implemented as software executing on general-purpose or application-specific hardware.

[0062] In one embodiment, a “reader” as used in this disclosure may include at least one reader module like reader module 602 and at least one local controller such as local controller 612. Such a reader may or may not include any remote controllers such as remote controller 622. A reader including a reader module and a local controller may be implemented as a standalone device or as a component in another device. In some embodiments, a reader may be implemented as a mobile device, such as a handheld reader, or as a component in a mobile device such as a laptop, tablet, smartphone, wearable device, or any other suitable mobile device.

[0063] Remote controller 622, if not included in a reader, may be implemented separately. For example, remote controller 622 may be implemented as a local host, a remote server, or a database, coupled to one or more readers via one or more communications networks. In some embodiments, remote controller 622 may be implemented as an application executing on a cloud or at a datacenter.

[0064] Functionality within reader system 600 may be distributed in any suitable way. For example, the encoding and / or decoding functionalities of blocks 604 and 606 may be performed by processor blocks 614 and / or 624. In some embodiments, processor blocks 614 and 624 may cooperate to execute an application or perform some functionality. One of local controller 612 and remote controller 622 may not implement memory, with the other controller providing memory.

[0065] Reader system 600 may communicate with at least one service 632. Service 632 provides one or more features, functions, and / or capabilities associated with one or more entities, such as reader systems, tags, tagged items, and similar. Such features, functions, and / or capabilities may include the provision of information associated with the entity, such as warranty information, repair / replacement information, upgrade / update information, and similar; and the provision of services associated with the entity, such as storage and / or access of entity -related data, location tracking for the entity, entity security services (e.g., authentication of the entity), entity privacy services (e.g., who is allowed access to what information about the entity), and similar. Service 632 may be separate from reader system 600, and the two may communicate via one or more networks.

[0066] In some embodiments, an RFID reader or reader system implements the functions and features described above at least partly in the form of firmware,software, or a combination, such as hardware or device drivers, an operating system, applications, and the like. In some embodiments, interfaces to the various firmware and / or software components may be provided. Such interfaces may include application programming interfaces (APIs), libraries, user interfaces (graphical and otherwise), or any other suitable interface. The firmware, software, and / or interfaces may be implemented via one or more processor blocks, such as processor blocks 614 / 624. In some embodiments, at least some of the reader or reader system functions and features can be provided as a service, for example, via service 632 or service 640.

[0067] FIG. 7 is a diagram of an example RFID tag IC memory configuration, according to embodiments. Diagram 700 depicts an RFID tag IC memory 750, similar to the physical memory configuration described in the Gen2 Protocol. Memory 750 includes four partitions or sections 752, 754, 756, and 758. Partition 752 (“user memory”) may be configured to store user data. Partition 754 (“TID memory”) may be configured to store an identifier for the tag IC itself, such as a tag identifier or TID. In some cases, the TID may include a mask designer identifier (MDID) identifying a manufacturer of the tag IC. Partition 756 (“EPC memory”) may be configured to store an identifier for an item associated with or attached to the tag IC, such as an electronic product code or EPC. Partition 758 (“Reserved memory”) may be configured to store information reserved for the tag IC itself or otherwise not necessarily publicly accessible, such as passwords, PINs, cryptographic keys, or similar. The Gen2 Protocol specifies that two passwords, the Access password and the Kill password, can be stored in partition 758. The Access password, if present, can be used to restrict certain tag IC operations as described in the Gen2 Protocol. The Kill password, if present, can be used to cause a tag IC to enter the Killed state as described in the Gen2 Protocol. As these passwords are sensitive, partition 758 is generally not publicly accessible.

[0068] The configuration of tag IC memory 750 is provided as an example. Tag IC memory can have any number of partitions configured to store any suitable information. Tag IC memories are generally implemented using nonvolatile memory, although in some examples volatile memory may be used to implement tag IC memory.

[0069] RFID tags are often configured to be responsive to commands received from any RFID reader, readily providing their unique identifier to any such reader. Whilethis feature is often not problematic in the business-case usage of RFID tags, consumers are increasingly purchasing items that are tagged with RFID tags and are also themselves attaching RFID tags to their own items. In some cases, a unique identifier of an RFID tag may reveal information about an item that the tag is associated with, or about the RFID tag itself. A consumer may have multiple RFID tags, each of which may provide their own identifier, potentially revealing information about the consumer, information about a consumer’s items to which RFID tags are attached to or embedded in, or information about the RFID tags themselves. Any third party can use an RFID reader to read unique identifiers from RFID tags of the consumer, which may intrude on the privacy of the consumer.

[0070] Tags may be configured to counteract this privacy issue. For example, some tags are configured with an operating mode in which they become nonresponsive permanently or semi-permanently, or such that they are unresponsive to commands until some authentication process has been successfully completed. However, as efforts toward sustainability and material recycling increase, some jurisdictions are implementing regulations that mandate items at their end of life (EOL) provide information related to their disposal or recycling. These regulations may require nonresponsive tags to uniformly be made responsive at the EOL of the tag and / or the EOL of the item that the tag is attached to, such that the tag can provide information related to the disposal or recycling of the tag or the item. Nonresponsive tags may maintain privacy protection, but it can be difficult to turn nonresponsive tags responsive at EOL, especially if doing so requires authentication.

[0071] One way to protect privacy without rendering tags unresponsive is to configure tags with an anonymous mode of operation in which they reply with anonymized identifiers. An anonymized identifier is an identifier which by itself does not provide information about an associated tag or item. Anonymized identifiers differ from unanonymized identifiers such as EPCs, which provide information about items, and TIDs, which provide information about tags or tag ICs. A tag operating in an anonymous mode (also referred to as an “anonymous tag”) will reply to a reader with an anonymized identifier instead of an unanonymized identifier, such as an EPC, TID, or other identifier that by itself provides information about the tag or associated item. For example, an anonymous tag may reply to a Gen2 ACK command with an anonymized identifier as opposed to its EPC.

[0072] While anonymized identifiers by themselves do not provide information about associated tags or items, they may be generated based on unanonymized tag or item identification information (e.g., tag or item identifiers). In these situations, an anonymized identifier may be deanonymized to provide tag or item identification information. Deanonymization of an anonymized identifier may require knowledge of some other information, as described below.

[0073] A tag may generate an anonymized identifier in any suitable way. An anonymized identifier intended to provide identification information should appear to be random, but be generated to allow recovery of the identification information. For example, a tag with some secret information (e.g., a cryptographic key, a password, or a personal identification number or PIN) may perform a computation using the secret information, an unanonymized identifier (e.g., an EPC or TID), and optionally other values to generate an anonymized identifier. If the secret information is a cryptographic key, the tag may encrypt or otherwise cryptographically process the unanonymized identifier and optional value(s) using the key to generate the anonymized identifier. In other examples, the tag may use any other suitable algorithm to generate the anonymized identifier.

[0074] The optional value(s) used to generate the anonymized identifier may include a random value and / or a known value. A random value used to generate the anonymized identifier may vary as a function of time or repetition, such that the resulting anonymized identifier is not static. For example, the random value could be based on a random number generated by the tag. In some examples, the random value may only be known to the tag. A known value used to generate the anonymized identifier may be a value that is known both to the tag and to some external service (e.g., a deanonymization service as described below). For example, the known value may be a fixed value (e.g., a string of zeroes of a certain length) or a variable value (e.g., a value generated by the tag and somehow provided to the external service). One example of a known value is a collision-resolution (CR) code generated by the tag and sent to a reader during inventorying.

[0075] As described above, an anonymized identifier may be generated based on an unanonymized identifier. However, in some examples an anonymized identifier may not be generated based on an unanonymized identifier - instead, it could be generated based on one or more known values, also described above.

[0076] An anonymized identifier by itself does not provide information about an associated tag or item. While this may be beneficial from a privacy standpoint, it may be problematic if an authorized entity such as the tag / item owner or some other service desires information about the tag / item.

[0077] One way to address this issue is for the tag to additionally provide some information that enables an authorized entity to more specifically identify the tag or associated item. This information may be referred to as a “hint.” Like the anonymized identifier, the hint by itself may not provide information about the associated tag or item. However, the hint is related to the anonymized identifier such that an authorized entity can use the hint, the anonymized identifier, and optionally some additional information to more specifically identify the tag or associated item.

[0078] A hint may be related to an anonymized identifier in several ways. First, a tag may generate the hint and the anonymized identifier based on similar or related values. For example, the tag may generate the hint and the anonymized identifier using a same starting value, such as an unanonymized identifier or some other fixed or variable value. As another example, the tag may generate the hint based on the anonymized identifier, or vice-versa. A value which is used to generate a hint may be referred to as a “code.” For example, if at least a portion of an anonymized identifier is used to generate a hint, the anonymized identifier may be referred to as an “anonymized identifier code.” A tag may generate a hint based on all of, or part of one or more codes. Note, however, that merely because something is referred to as a “code” does not mean that it is or must be used to generate a hint.

[0079] Second, a tag may generate the hint and the anonymized identifier using the same process. For example, the tag may use the same algorithm to generate both the anonymized identifier and the hint. As another example, the tag may generate the anonymized identifier and the hint by using the same tag key in a cryptographic process.

[0080] An anonymous tag may generate hints based on any suitable information or code that is either separately provided by the tag or otherwise known by an authorized entity. For example, the anonymous tag may generate hints based on an anonymized identifier, an unanonymized identifier, and / or a random number (e.g., a CR code). In some example, a hint may include a portion of a tag or item identifier which is notsubstantial enough to identify a specific anonymous tag or tag key but is sufficient to eliminate at least some potential tags or keys. In other examples, a hint may include a wafer location identifier for a tag IC that identifies a wafer on or wafer location at which the tag IC was fabricated.

[0081] Of course, a tag may generate a hint in any suitable way using any suitable inputs, as long as an authorized entity can later use the hint to assist in more specifically identifying the tag or associated item.

[0082] When an anonymous tag generates an anonymized identifier or a hint, it may truncate or pad the input and / or output in order to achieve a desired identifier or hint length. For example, if a tag generates an anonymized identifier or hint using a cryptographic algorithm, then the tag may truncate (i.e., shorten by removing portions of) or pad (i.e., add one or more bits to) an input into the cryptographic algorithm, or it may truncate or pad the output of the cryptographic algorithm to obtain the anonymized identifier or hint.

[0083] As described above, neither an anonymized identifier nor a hint provide enough information alone to identify an associated tag or item. However, an authorized entity may be able to use the combination of the hint and any codes upon which the hint is based on (which could be the anonymized identifier) to at least begin identifying the associated tag or item.

[0084] Combinations of hints and codes upon which the hints are based may be referred to as “code-hint sets”. A code-hint set links a particular hint to the particular code value(s) used to generate that hint, using a certain algorithm. Further, the codehint set may link that specific hint and those specific code value(s) to an identifier associated with a tag that could have generated that specific hint from those specific code value(s). In some examples, the hint and each code value of a code-hint set may individually be referred to as an “index” of the set, while the identifier may be referred to as an “element” or “entry” of the set. For example, a code-hint set including a hint and two associated code value(s) includes three indices: the hint, the first associated code value, and the second associated code value.

[0085] Authorized entities may have access to such code-hint sets. When an authorized entity with such access receives a hint and the code(s) upon which the hint is based from an originating tag, it attempts to match the received hint and code(s) toa known code-hint set. Upon finding the code-hint set that includes both the received hint and the received code(s), it can then use the identifier associated with that codehint set to more specifically identify the originating tag.

[0086] In one specific implementation, hints are generated based on only one code. In this implementation, a code-hint set includes two indices: a hint and a code from which the hint is generated. The code-hint set further includes an identifier associated with the hint and code of the set. For simplicity, such a code-hint set may be referred to as a “code-hint pair,” because it only contains two indices - a hint and a code.

[0087] In some circumstances, code-hint sets may be organized into a multidimensional array. Referring to the previous example, code-hint pairs may be organized into a two-dimensional array or table, with hints along one axis of the array or table, codes along another axis, and identifiers as elements or entries within the array or table. Such a table is depicted in FIG. 8, described below.

[0088] For example, an authorized entity receiving a hint and a single code may use the hint and code as indices to determine or look up corresponding identifier(s) in a two-dimensional array or table of code-hint pairs. In this example, the authorized entity may use the hint as a first index on one axis of the table, use the code as a second index on the other axis of the table, then find the corresponding identifier(s) at the entry associated with the first and second indices.

[0089] As described above, a code-hint set may include an identifier associated with a tag that could have generated the respective hint from the respective code(s) in the code-hint set. The identifier may identify a specific tag or item (e.g., like a TID or an EPC), and if so, the authorized entity can immediately identify the associated tag or item.

[0090] The identifier may instead identify something about a specific tag or item. In this case, the authorized entity can use the identifier to determine more information about the tag or item. In one example, the identifier may identify how the tag generates an anonymized identifier. For example, if the tag generates an anonymized identifier by cryptographically processing a tag or item identifier using a tag key, the identifier recovered from the code-hint set may provide information about the tag key and / or specifics about the cryptographic processing. An authorized entity having this cryptographic information and the anonymized identifier can then use thecryptographic information to recover the tag or item identifier from the anonymized identifier, thereby identifying the associated tag or item.

[0091] Code-hint sets may be constructed by any suitable entity. For example, a tag IC manufacturer with access to tag identifiers and tag keys may construct code-hint sets using this information. In some examples, such an entity may provide the information or access to the information to another authorized entity, which then constructs the code-hint sets.

[0092] FIG. 8 is a block diagram illustrating an RFID system 800 enabling the use of anonymous tags, according to embodiments. The RFID system 800 includes a tag 802, a reader 808, an application 810, and a deanonymization service 812. The system 800 may also include an optional registration service 816 and an optional information service 820.

[0093] Tag 802, which may be configured with an anonymous mode of operation, has an associated identifier / ID 804 and key 806. When reader 808 attempts to inventory tag 802, it may transmit one or more inventorying commands S850, such as a Query command as described in the Gen2 Protocol or other similar query-type commands. In response, tag 802 may send a reply S852 including a CR code, for example an RN16 as described in the Gen2 Protocol. Reader 808 may then transmit an acknowledgement command S854 including the CR code, such as an ACK command as described in the Gen2 Protocol. Upon determining that the command S854 includes the correct CR code, tag 802 may then respond. If operating in the anonymous mode, tag 802 may respond by sending a reply S856 including an anonymized identifier code and a hint, both as described above. For example, tag 802 may generate the anonymized identifier and / or hint using key 806 and a cryptographic algorithm. Tag 802 may generate the anonymized identifier code and / or the hint at power-up, upon receiving the inventorying command(s) S850, or at any other suitable time. If the hint is based on the anonymized identifier code or the CR code, then the hint is necessarily generated after those codes have been generated.

[0094] Reader 808 then sends (S858) the anonymized identifier code and hint, and optionally the CR code, received from tag 808 to an application 810. Application 810 may be a software program executing on the reader 808 or on a device including or communicatively coupled to reader 808, or may be a network service accessible byreader 808. Application 810 is not an “authorized entity” as described above, and so is unable to discern any identification information about tag 802 (for example, the identifier 804 or the key 806) from the anonymized identifier code, hint, and optional CR code. If application 810 provides some function involving knowledge of the identity of tag 802, then application 810 may communicate with an authorized entity to discern some identification information about tag 802. Application 810 may also communicate with the authorized entity merely to forward information read from RFID tags.

[0095] Application 810 may identify authorized entities in any suitable way. For example, application 810 may be configured to automatically communicate with a certain authorized entity when necessary. In some examples, application 810 may maintain or have access to a list of authorized entities to select from when communication with an authorized entity is necessary. In other examples, application 810 may request an appropriate authorized entity from a network service when necessary. In some examples, the tag itself may send information identifying an authorized entity.

[0096] In FIG. 8, deanonymization service 812 is such an authorized entity.Accordingly, application 810 sends (S860) the information received from reader 808 regarding tag 802 (i.e., the anonymized identifier code, hint, and optionally the CR code) to the deanonymization service 812. Application 810 may be configured to secure communications to such services, for example by establishing a secure communication channel.

[0097] Deanonymization service 812, as an authorized entity, has access to certain code-hint sets, as described above. For example, deanonymization service 812 may operate or have access to one or more databases containing code-hint pairs, depicted as a code-hint table 814 in FIG. 8. A code-hint table such as code-hint table 814 may have entries or elements that are indexed by a code on one axis and a hint on another axis. For example, code-hint table 814 has rows that correspond to different code values and columns that correspond to different hint values. A given code-hint pair having a specific code value, a specific hint value, and a specific identifier value is represented in the code-hint table 814 as an entry in a cell of the code-hint table 814, where the cell is located at the intersection of the row corresponding to the specificcode value and the column corresponding to the specific hint value and contains the specific identifier value.

[0098] The size of any code-hint table (or of any database that stores code-hint sets) depends on the lengths of the codes and the hints. If the rows of a code-hint table correspond to codes, then the code-hint table may have one row per potential code value. Similarly, if the columns of a code-hint table correspond to hints, then the code-hint table may have one column per potential hint value. The number of potential code values may not necessarily be the same as the number of potential hint values, meaning that a code-hint table may not have the same number of rows and columns.

[0099] As described above, hints may be generated based on at least a portion of a code, for example, by processing at least a portion of a code. Suppose that a code is either a 16-bit CR code (e.g., an RN16 according to the Gen2 Protocol) or a 16-bit anonymized identifier code. The hint may be generated by encrypting the code with a tag key and taking the 16 least significant bits (LSBs) of the encryption. In this example, there are 216possible values both for the code and the hint, and accordingly the resulting code-hint table has a size of 216x 216, where each row (or column) corresponds to a different code value and each column (or row) corresponds to a different hint value. If anonymous tags are configured to generate hints based on a portion of a code smaller than the entire code, then the code-hint table may have rows (or columns) including the entire code, or only the portion of the code that is used to generate the hint. As is evident, an index (e.g., code or hint) may be assigned to either a table row or column without loss of functionality.

[0100] A cell of a code-hint table is indexed by a specific code value and specific hint value and may store an identifier value associated with a tag that could have generated the respective specific hint value from the respective specific code value. In some examples, the identifier value may be or identify a key (e.g., key 806) associated with the tag. In the latter case, the identifier value may be used to look up (e.g., from another database or service) or derive the key. In some situations, one or more cells of a code-hint table may be empty or may contain multiple entries. An empty cell means that no tag could have generated the hint indexed by that cell based on the code indexed by that cell. A cell with multiple entries means that multiple tags could have generated the hint indexed by that cell based on the code indexed by that cell. Forexample, the latter situation may arise because it is possible for multiple unique tag keys, when used to encrypt a given code, to provide results that share the same LSBs or MSBs used as the hint.

[0101] After receiving the information regarding tag 802 (e.g., the anonymized identifier code, hint, and optionally the CR code), the deanonymization service 812 may use the information (S862) to identify one or more identifiers via the code-hint database. For example, if the hint is based on the CR code, the deanonymization service 812 may use the hint and the CR code to look up one or more identifiers in the database depicted by code-hint table 814. As one specific example, if the CR code has the value “CODE 1” and the hint has a value “HINT 1”, then the resulting identifier is “idl,” as shown in table 814.

[0102] As described above, the entries of a code-hint database may include keys or identifiers used to identify keys. In either case, once deanonymization service 812 has determined a candidate key associated with the provided code and hint, it may use the candidate key to recover an identifier from the anonymized identifier code.Deanonymization service 812 may then provide the recovered identifier to application 810 if requested and authorized. Deanonymization service 812 may also provide the recovered identifier and associated information to one or more other services, for example to notify designated entities as described below.

[0103] In some situations, a given code-hint pair may correspond with multiple entries or identifiers, as described above. For example, referring to table 814, “CODE 1” and “HINT 4” corresponds to identifiers “id8” and “idl 1.” In this situation, the deanonymization service 812 may attempt to identify the “correct” identifier - that is, the identifier identifying or corresponding to the key of the originating tag (in this case, key 806 of tag 802).

[0104] A service, such as deanonymization service 812, may determine a correct identifier in several ways. For example, the service may attempt to recover unanonymized identifiers from an anonymized identifier code using keys associated with identifiers. If the service successfully recovers a correct unanonymized identifier using a certain key, then that key and its corresponding identifier may be considered correct. The service may determine that an unanonymized identifier is correct if the unanonymized identifier exists or is in-service. An identifier “exists” or is “in-service” when it is associated with a tag or item that has not yet been disposed of. The service may have access to information about whether identifiers exist or are inservice, or may consult another service having access to such information.

[0105] The service may also determine that an unanonymized identifier is correct if the unanonymized identifier is correctly associated with the key used to recover it. For example, suppose that a given code and hint correspond to multiple identifiers, like how “CODE 1” and “HINT 4” in table 814 correspond to identifiers “id8” and “idl 1.” Each identifier is associated with a different key, each key is associated with a different tag, and each tag has a different unanonymized identifier (assuming that keys and tag identifiers are relatively unique). When the keys are used to recover candidate unanonymized identifiers from a particular anonymized identifier code, only one of the keys will lead to a recovered unanonymized identifier that matches the key used, which the service may deem the “correct” unanonymized identifier. The other keys will not be able to recover their corresponding correctly associated unanonymized identifier from the particular anonymized identifier code.

[0106] In some examples, if the identifiers in the code-hint sets are unanonymized identifiers, then the service can simply check whether the recovered unanonymized identifier matches the identifier associated with the key used. If so, then the identifier, key, and recovered unanonymized identifier may be considered correct. However, a tag may have or be associated with multiple identifiers. In these instances, an unanonymized identifier recovered from a tag’s anonymized identifier code may not match the identifiers known to the service. If so, the service may need to consult another source or service to determine whether the recovered unanonymized identifier is correctly associated with the key used to recover it.

[0107] As mentioned above, a tag may have multiple identifiers. Such identifiers may include IC identifiers and item identifiers. An IC identifier, such as a tag identifier (TID), identify the tag IC of a tag, and often are programmed into tag ICs during manufacture. An item identifier, such as an electronic product code or EPC, provides information about the item associated with the tag, and may be programmed into the tag at or after the tag IC manufacture, such as when the tag is attached to an item. In some examples, a registration service, such as registration service 816 in FIG. 8, may know how these different identifiers relate to each other. For example, the registration service may know that a certain item identifier is associated with a certain tagidentifier, and vice versa. In some examples, the registration service may maintain these relationships in an identifier database, an example of which is depicted as table 818. In table 818, item identifiers (e.g., “I_ID 1”) are shown as related to IC identifiers (e.g., “IC IDENTIFIER 1”). A registration service may assist other services or entities, if authorized, in determining the multiple identifiers associated with tags or items. For example, the registration service may receive an item or IC identifier from an authorized requester, determine whether the received identifier corresponds to one or more different item or IC identifiers, and reply to the requester with the different identifier(s) and / or with an indication as if other identifiers were or were not found. As another example, the registration service may indicate to an authorized requester whether multiple item or IC identifiers correspond to each other (i.e., all refer to the same tag or item).

[0108] A registration service may also have access to information about whether identifiers, unanonymized or otherwise, exist or are in-service, as described above. If so, then the registration service may use this information to assist other services or entities, if authorized, in determining whether a given identifier exists or is in-service.

[0109] Referring back to FIG. 8, deanonymization service 812 may communicate with registration service 816 to determine whether known identifiers (e.g., from the database depicted by table 814) correspond to recovered unanonymized identifiers. Deanonymization service 812 may send (S864) the known identifiers and / or the recovered unanonymized identifiers to registration service 816. Registration service 816, after accessing (S866) its identifier relationship information, partly depicted by table 818, may respond (S868) by sending corresponding identifiers or indicating whether the known identifiers correspond to the recovered unanonymized identifiers. If registration service 816 also has access to information about existing or in-service identifiers, it may also or alternatively indicate whether the provided identifiers exist or are in-service.

[0110] A service may also determine whether an identifier is correct if its corresponding key allows the recovery of a correct known value. As mentioned above, anonymous tags may be configured to include a known value, known both by the anonymous tag and to the authorized entities, in an anonymized identifier code. In this situation, the service may determine whether a key recovers the known valuefrom the anonymized identifier code. If so, then the service may consider an identifier also recovered from the anonymized identifier code to be correct.[oni] A service may determine that an identifier is correct based on any other suitable process. For example, if the service only identifies one identifier, then the service may assume that it is correct, although in this instance it still may be desirable to confirm that the identifier is correct via one of the methods described above. In another example, the service may determine that an identifier is correct if its associated key recovers an unanonymized identifier with the proper encoding or format (e.g., the recovered identifier has a format expected of an identifier or “looks like” an identifier). A service may also determine identifier correctness based on other data, such as location data or history data associated with the identifier.

[0112] Once deanonymization service 812 has determined the correct identifier, it may recover an unanonymized identifier - for example, the identifier 804 - from the anonymized identifier code, if it hasn’t already. Deanonymization service 812 may then send (S870) the unanonymized identifier back to application 810, if authorized.

[0113] Deanonymization service 812 may also (or instead) take one or more actions related to one or more entities. For example, deanonymization service 812 may notify one or more other entities that the tag corresponding to the unanonymized identifier (i.e., tag 802) has been read. A tag or item may be associated with one or more designated entities, such as an owner, a caretaker, or similar entity. Services (e.g., the deanonymization service 812 and / or the registration service 816) may be configured to, when a tag is read, take one or more actions with respect to the designated entities. For example, when deanonymization service 812 receives information about tag 802, the service 812 may be configured to identify and notify a designated entity associated with tag 802. The service 812 may itself know designated entities associated with tags and items, for example based on unanonymized identifiers, or may communicate with one or more other services to identify such designated entities. In some examples, the designated entity may include a reader such as the reader 808, an application such as the application 810, and / or a user of the reader or application.

[0114] The service 812 may notify the designated entity by sending the unanonymized identifier, the identifier from the database depicted by code-hint table814, and / or another identifier determined via, for example, registration service 816. The service 812 may also send additional data, such as an identifier for the reader 808, the application 810, an entity associated with application 810, a time or location associated with when tag 802 was read, or any other suitable information. A designated entity may take any suitable action upon receiving such a notification. For example, the designated entity may update a record associated with tag 802, seek additional information about the detection of tag 802 (e.g., the identity of the detector, the time and / or location of the detection, etc.), grant or deny permission to access certain information about tag 802, etc. In some examples, other services or authorized entities may be configured to and perform these actions.

[0115] While examples above describe a scenario where an anonymized identifier code is deanonymized based on a code and a hint, other scenarios are possible.Anonymous tags may be configured to only provide a hint without a code, to provide multiple hints and codes, or otherwise. If anonymous tags are configured to only provide a hint, then a hint database may store identifiers indexed solely by the different possible hint values. If anonymous tags are configured to provide multiple hints and codes, then a database may store identifiers indexed by the different possible hint values and code values. In one such example, an anonymous tag may be configured to provide a first hint based on an anonymized identifier code, the anonymized identifier code, a second hint based on a CR code, and the CR code.

[0116] If application 810 receives the unanonymized identifier, identifier 804, from deanonymization service 812, it may send it on to reader 808 if authorized.Application 810 may also or instead use the identifier 804 to determine additional information about tag 802, especially if application 810 is configured to provide some function involving tag or item information. For example, application 810 may send (S872) identifier 804 or associated information to information service 820 to determine or retrieve information about tag 802. Application 810 may identify information service 820 using identifier 804 or via some other means. The information service 820 may know relationships between tag identifiers and other information, such as the manufacturer, model, color, composition, disposal or recycling information, owner, owner contact information, or any other information associated with tags, tagged items, or owners of tagged items. The information service 820 may limit access to some information - for example, it may limit owner or ownercontact information to only be accessible by the owner themselves or by authorized entities. Other information, such as disposal or recycling information, may be available regardless of owner approval.

[0117] After receiving identifier 804 from application 810, the information service 820 may retrieve information associated with identifier 804. The information service 820 may provide some or all information available. In some examples, the information service 804 may be configured to contact a designated entity associated with the tag 802 to determine what information should be provided to application 810. The information service 820 may then send (S874) the information, if any, to application 810.

[0118] The steps described above allow an entity such as application 810 to obtain information about the anonymous tag 802, including its identifier 804 and information associated with the anonymous tag 802, the item it is attached to, or the owner of the anonymous tag 802, without the anonymous tag 802 having to provide the information. Instead, the anonymous tag 802 initially only provides an anonymized identifier code, a hint, and a CR code, all of which provide no identifying information about the anonymous tag 802 or its owner. Identifying information is obtained only after the deanonymization service 812 uses the anonymized identifier code, the hint, and optionally the CR code to recover identifier 804 from the anonymized identifier code. In some examples, the deanonymization service 812 may only provide the unanonymized identifier 804 after determining that a requestor is authorized.

[0119] A similar scheme may be used to authenticate (i.e., verify the identity of) the anonymous tag 802. In one authentication scheme, a challenge is first sent to the anonymous tag 802 by the deanonymization service 812, for example, via the application 810. The challenge is known by the deanonymization service 812 and may include a random number, which may act as the “known information” described above. The anonymous tag 802 may generate a response to the challenge by encrypting at least a portion of the challenge with its tag key 806. The anonymous tag 802 may then send the response and the identifier 804 to deanonymization service 812 via the application 810. The deanonymization service 812 may retrieve the tag key 806 using the identifier 804. The deanonymization service 812 may thereafter decrypt the response using the retrieved tag key 806. If the decryption corresponds to at least a portion of the originally sent challenge, then the deanonymizations service 812 maydetermine that the anonymous tag 802 is authentic (i.e., the anonymous tag 802 knows the tag key 806 associated with the identifier 804 that it sent).

[0120] One modification to this authentication scheme may include the anonymous tag 802 sending a code and hint instead of a tag identifier. In this example, the deanonymization service 812 may perform at least some of the steps described above to identify the tag key 806 using the code and hint. If the anonymous tag 802 also sends an encrypted version of the identifier 804, included in or separate from the encrypted response package, then the deanonymization service 812 may also confirm the correctness of the tag key 804.

[0121] FIG. 9 is a flow diagram illustrating a method 900 for a service to deanonymize an anonymous RFID tag, according to embodiments. A service may be one or more of the services described above in FIG. 8, and may operate in a similar manner to any of the services described.

[0122] At block 902, a service may receive a deanonymization request including an anonymized identifier code, a hint, and optionally a collision-resolution (CR) code. The anonymized identifier code, the hint, and the CR code may originate from an anonymous tag, for example, when the anonymous tag is being inventoried by a reader that has transmitted the deanonymization request to the service.

[0123] At block 904, the service may identify a key associated with the anonymous tag using the hint and the code used to generate the hint. The service may be configured with prior knowledge of what code anonymous tags are configured to generate hints based on, or it may determine what code is used based on which code is received. For example, if no CR code is received, then the service may determine that the hint is generated based on the anonymized identifier code. Similarly, if a CR code is received, then the service may determine that the hint is generated based on the CR code. The service may use the received code and hint to access a code-hint database which stores identifiers, such as tag keys or key identifiers. If the stored identifiers are key identifiers, then the service may resolve or derive tag keys from the key identifiers. In some examples, the service may identify one or more candidate tag keys from the code-hint database, and may jointly confirm a correctness of one of the candidate tag keys along with candidate identifiers at block 906 below.

[0124] At block 906, the service may recover an unanonymized identifier from the anonymized identifier code. The service may use an identified tag key to decrypt an anonymized identifier code, recovering an identifier of the anonymous tag in the process. The service may also verify that the recovered identifier is correct. This may be especially relevant if the service identifies multiple candidate tag keys above at block 904. The service may verify a correctness of a candidate identifier and / or the correctness of a candidate tag key jointly in a number of different manners. For example, the service may determine that an identifier or tag key is correct based on: if a candidate identifier exists, if a candidate tag key can be used to recover a candidate identifier from the anonymized identifier code that is correctly associated with the candidate tag key, if a candidate tag key recovers a known value from the anonymized identifier code, a combination of any of the previously stated, or otherwise.

[0125] At block 908, the service may determine one or more entity designations, thereby identifying one or more designated entities associated with the recovered identifier, as described above. For example, the service may know information about designated entities, or may communicate with one or more other services to identify such designated entities. The entity designation may also be based on an originator of the deanonymization request, such as an entity that originally transmitted the request to the service.

[0126] At block 910, the service may then transmit the recovered identifier to the designated entity. The service may also transmit any other information associated with the identifier, which may be obtained from another entity.

[0127] Interactions between the service and other entities may be optimized to reduce the computational or procedural load on the service and / or the other entities. For example, if a deanonymization service is at least partially distinct from a registration service, requests and responses to and from the entities may be batched in a number of different ways. For example, if a deanonymization service identifies one tag key multiple times (e.g., as shown by the code-hint table 814, the key identifier id2 may be obtained from “HINT 1 / CODE 2” and from “HINT 3 / CODE 3”) which may lead to multiple requests to resolve the same identifier to the registration service, those multiple requests may instead be batched together. In general, requests and responses may be batched to reduce the volume of communications between different entities, or between different parts of the same entity.

[0128] FIG. 10 is a flow diagram illustrating a method 1000 for an RFID tag to anonymize its identifier, according to embodiments The RFID tag is configured to operate in an anonymous mode. As stated above, when the RFID tag operates in the anonymous mode, it may be referred to as an “anonymous tag”.

[0129] At block 1002, the anonymous tag may receive a first inventorying command from a reader. Example of the first inventorying command may include a query-type command, such as a Query command of the Gen2 Protocol.

[0130] At block 1004, in response to receiving the first inventorying command, the anonymous tag may generate a collision-resolution (CR) code. In one example, the CR code may be an RN16 as described by the Gen2 Protocol. After generating the CR code, the anonymous tag may reply to the first inventorying command with the CR code.

[0131] At block 1006, the anonymous tag may then receive a second inventorying command from the reader. The second inventorying command may be an acknowledgment command that includes the previously tag-sent CR code. One example of an acknowledgement command is an ACK command of the Gen2 Protocol.

[0132] At block 1008, the anonymous tag may generate an anonymized identifier code. The generation of the anonymized identifier code may include cryptographically processing an identifier of the tag and a random number with a tag key of the anonymous tag. In some examples, the anonymized identifier code may also be formed using a known value, such as a known string or a portion of the CR code sent by the tag at block 1004. The anonymous tag may generate the anonymized identifier code at or after tag power-up, as long as the necessary components (e.g., the CR code) have been generated.

[0133] At block 1010, the anonymous tag may generate a hint based on a code. For example, the hint may be generated based on the CR code and / or the anonymized identifier code. In one example, the hint may be generated by cryptographically processing at least a portion of the CR code with the tag key. If the hint is generated based on the CR code, then it is possible that the hint is constrained by the time available in an inventory round because some anonymous tags may be configured to generate CR codes in response to receiving inventorying commands. In anotherexample, the hint may be generated by cryptographically processing a least a portion of the anonymized identifier code with the tag key. In this example, the tag may generate the hint at any time after generating the anonymized identifier code. The latter may be particularly advantageous in certain situations, as hint generation is not constrained by the available time in the inventory round.

[0134] At block 1012, the anonymous tag may respond to the second inventorying command by sending the anonymized identifier code and the hint to the reader.

[0135] Embodiments provide for a number of technical advantages. One example advantage is that the response of an anonymous tag in inventorying rounds appears to be random, because there is no easy way to recover a consistent identifier for the tag. While the reply of an anonymous tag may include some static parameters, said parameters may be shared across many tags and may therefore not be able to be used to identify the specific anonymous tag within a reasonable timeframe. That said, the static parameter may be used as an input to some function that transforms or combines the static parameter with a random value. For example, an identifier of a tag may be a static parameter but it is only sent within an anonymized identifier code after it is encrypted in combination with some randomness, which means that the anonymized identifier code also varies randomly. The anonymized identifier code does not reveal anything about its underlying identifying information, and the identifying information remains private until it is decrypted, for example, after a deanonymization service obtains sufficient information from a reader about an anonymous tag to identify the anonymous tag.

[0136] According to some examples, a method for identifying items may include receiving, from a requesting entity, an anonymized identifier code, a hint, and optionally a second code, where the anonymized identifier code, the hint, and the second code originate from wireless communications with a radio IC associated with a tagged item; identifying a key associated with the radio IC by comparing the hint and at least a portion of one of the received codes to a plurality of code-hint pairs; using the identified key to recover an identifier from the anonymized identifier code; determining an entity designation for the tagged item; and sending the recovered identifier to the designated entity.

[0137] According to other examples, the hint may be based on at least a portion of at least one of the received codes. The hint may be generated by using the key to cryptographically process the at least a portion of at least one of the received codes. The second code may be used to resolve collided responses in the wireless communications. The identifier may include at least one of an item identifier or an IC identifier. The anonymized identifier code may be based on at least the identifier and a random number. Identifying the key associated with the radio IC may include comparing the hint and the at least a portion of one of the received codes to the plurality of code-hint pairs to identify a plurality of candidate keys; and identifying a first one of the candidate keys as the key by one or more of: determining that the first candidate key is associated with an identifier that is in-service, determining that a candidate identifier recovered from the anonymized identifier code using the first candidate key is associated with the first candidate key, or determining that the first candidate key recovers a known value from the anonymized identifier code.

[0138] According to further examples, comparing the hint and the at least a portion of one of the received codes to the plurality of code-hint pairs may include accessing a code-hint table having one or more entries identifying one or more keys. The entity designation may designate at least one of: the requesting entity, or an owner of the tagged item.

[0139] According to yet other examples, a deanonymization service configured to identify items may include a processing block configured to perform actions associated with identifying items as described herein.

[0140] As mentioned previously, embodiments are directed to providing access to non-sensitive information while protecting identifying information stored on an RFID tag. Embodiments additionally include programs, and methods of operation of the programs. A program is generally defined as a group of steps or operations leading to a desired result, due to the nature of the elements in the steps and their sequence. A program is usually advantageously implemented as a sequence of steps or operations for a processor but may be implemented in other processing elements such as FPGAs, DSPs, or other devices as described above.

[0141] Performing the steps, instructions, or operations of a program requires manipulating physical quantities. Usually, though not necessarily, these quantitiesmay be transferred, combined, compared, and otherwise manipulated or processed according to the steps or instructions, and they may also be stored in a computer-readable medium. These quantities include, for example, electrical, magnetic, and electromagnetic charges or particles, states of matter, and in the more general case can include the states of any physical devices or elements. Information represented by the states of these quantities may be referred-to as bits, data bits, samples, values, symbols, characters, terms, numbers, or the like. However, these and similar terms are associated with and merely convenient labels applied to the appropriate physical quantities, individually or in groups.

[0142] Embodiments furthermore include storage media. Such media, individually or in combination with others, have stored thereon instructions, data, keys, signatures, and other data of a program made according to the embodiments. A storage medium according to embodiments is a computer-readable medium, such as a memory, and can be read by a processor of the type mentioned above. If a memory, it can be implemented in any of the ways and using any of the technologies described above.

[0143] Even though it is said that a program may be stored in a computer-readable medium, it does not need to be a single memory, or even a single machine. Various portions, modules or features of it may reside in separate memories, or even separate machines. The separate machines may be connected directly, or through a network such as a local access network (LAN) or a global network such as the Internet.

[0144] Often, for the sake of convenience only, it is desirable to implement and describe a program as software. The software can be unitary or thought of in terms of various interconnected distinct software modules.

[0145] The foregoing detailed description has set forth various embodiments of the devices and / or processes via the use of block diagrams and / or examples. Insofar as such block diagrams and / or examples contain one or more functions and / or aspects, each function and / or aspect within such block diagrams or examples may be implemented individually and / or collectively, by a wide range of hardware, software, firmware, or virtually any combination thereof. Some aspects of the embodiments disclosed herein, in whole or in part, may be equivalently implemented employing integrated circuits, as one or more computer programs running on one or more computers (e.g., as one or more programs running on one or more computer systems),as one or more programs running on one or more processors (e.g. as one or more programs running on one or more microprocessors), as firmware, or as virtually any combination thereof, and that designing the circuitry and / or writing the code for the software and / or firmware would be well within the skill of one of skill in the art in light of this disclosure.

[0146] The present disclosure is not to be limited in terms of the particular embodiments described in this application, which are intended as illustrations of various aspects. Many modifications and variations can be made without departing from its spirit and scope. Functionally equivalent methods and apparatuses within the scope of the disclosure, in addition to those enumerated herein, will be apparent to those skilled in the art from the foregoing descriptions. Such modifications and variations are intended to fall within the scope of the appended claims. The present disclosure is to be limited only by the terms of the appended claims, along with the full scope of equivalents to which such claims are entitled. It is to be understood that this disclosure is not limited to particular methods, configurations, tags, RFICs, readers, systems, and the like, which can, of course, vary. It is also to be understood that the terminology used herein is for the purpose of describing particular embodiments only, and is not intended to be limiting.

[0147] With respect to the use of substantially any plural and / or singular terms herein, those having skill in the art can translate from the plural to the singular and / or from the singular to the plural as is appropriate to the context and / or application. The various singular / plural permutations may be expressly set forth herein for sake of clarity.

[0148] In general, terms used herein, and especially in the appended claims (e.g., bodies of the appended claims) are generally intended as “open” terms (e.g., the term “including” should be interpreted as “including but not limited to,” the term “having” should be interpreted as “having at least,” the term “includes” should be interpreted as “includes but is not limited to,” etc.). If a specific number of an introduced claim recitation is intended, such an intent will be explicitly recited in the claim, and in the absence of such recitation no such intent is present. For example, as an aid to understanding, the following appended claims may contain usage of the introductory phrases "at least one" and "one or more" to introduce claim recitations. However, the use of such phrases should not be construed to imply that the introduction of a claimrecitation by the indefinite articles "a" or "an" limits any particular claim containing such introduced claim recitation to embodiments containing only one such recitation, even when the same claim includes the introductory phrases "one or more" or "at least one" and indefinite articles such as "a" or "an" (e.g., “a” and / or “an” should be interpreted to mean “at least one” or “one or more”); the same holds true for the use of definite articles used to introduce claim recitations. In addition, even if a specific number of an introduced claim recitation is explicitly recited, such recitation should be interpreted to mean at least the recited number (e.g., the bare recitation of "two recitations," without other modifiers, means at least two recitations, or two or more recitations).

[0149] Furthermore, in those instances where a convention analogous to “at least one of A, B, and C, etc.” is used, in general such a construction is intended in the sense one having skill in the art would understand the convention (e.g., “a system having at least one of A, B, and C” would include but not be limited to systems that have A alone, B alone, C alone, A and B together, A and C together, B and C together, and / or A, B, and C together, etc.). Any disjunctive word and / or phrase presenting two or more alternative terms, whether in the description, claims, or drawings, should be understood to contemplate the possibilities of including one of the terms, either of the terms, or both terms. For example, the phrase “A or B” will be understood to include the possibilities of “A” or “B” or “A and B.”

[0150] For any and all purposes, such as in terms of providing a written description, all ranges disclosed herein also encompass any and all possible subranges and combinations of subranges thereof. Any listed range can be easily recognized as sufficiently describing and enabling the same range being broken down into at least equal halves, thirds, quarters, fifths, tenths, etc. As a non-limiting example, each range discussed herein can be readily broken down into a lower third, middle third and upper third, etc. All language such as “up to,” “at least,” “greater than,” “less than,” and the like include the number recited and refer to ranges which can be subsequently broken down into subranges as discussed above. Finally, a range includes each individual member. Thus, for example, a group having 1-3 cells refers to groups having 1, 2, or 3 cells. Similarly, a group having 1-5 cells refers to groups having 1, 2, 3, 4, or 5 cells, and so forth.

Claims

CLAIMSWE CLAIM:

1. A method for identifying items, the method comprising:receiving, from a requesting entity, an anonymized identifier code, a hint, and optionally a second code, wherein the anonymized identifier code, the hint, and the second code originate from wireless communications with a radio IC associated with a tagged item;identifying a key associated with the radio IC by comparing the hint and at least a portion of one of the received codes to a plurality of code-hint pairs;using the identified key to recover an identifier from the anonymized identifier code;determining an entity designation for the tagged item; andsending the recovered identifier to the designated entity.

2. The method of claim 1, wherein the hint is based on at least a portion of at least one of the received codes.

3. The method of claim 2, wherein the hint is generated by using the key to cryptographically process the at least a portion of at least one of the received codes.

4. The method of claim 1, wherein the second code is used to resolve collided responses in the wireless communications.

5. The method of claim 1, wherein the identifier includes at least one of an item identifier or an IC identifier.

6. The method of claim 1, wherein the anonymized identifier code is based on at least the identifier and a random number.

7. The method of claim 1, wherein identifying the key associated with the radio IC comprises:comparing the hint and the at least a portion of one of the received codes to the plurality of code-hint pairs to identify a plurality of candidate keys; andidentifying a first one of the candidate keys as the key by one or more of: determining that the first candidate key is associated with an identifier that is in-service,determining that a candidate identifier recovered from the anonymized identifier code using the first candidate key is associated with the first candidate key, ordetermining that the first candidate key recovers a known value from the anonymized identifier code.

8. The method of claim 1, wherein comparing the hint and the at least a portion of one of the received codes to the plurality of code-hint pairs comprises accessing a code-hint table having one or more entries identifying one or more keys.

9. The method of claim 1, wherein the entity designation designates at least one of:the requesting entity, oran owner of the tagged item.

10. A deanonymization service configured to identify items, the deanonymization service comprising:a processing block configured to perform actions of claims 1 through 9.

Images